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Kapitel  1 


Motivation 


Angesichts  der  komplizierten  Bewegungsprobleme  kann  sich  die  Bahn-  und  Parame- 
terbestimmung in  der  Satellitengeodäsie  und  Himmelsmechanik  meist  nicht  auf  ana- 
lytisch formulierte  Lösungen  stützen.  Zudem  wurde  die  Genauigkeit  der  Ortungs- 
und Bahnverfolgungsverfahren  wie  auch  der  satellitengestützten  Messverfahren  in  den 
letzten  Jahren  beträchtlich  gesteigert,  was  eine  Verbesserung  der  numerischen  Verfah- 
ren zur  Verarbeitung  der  Daten  unverzichtbar  macht.  Zwei  Beispiele  seien  angeführt: 

1.  Die  Satellitenmission  GRACE  zur  Schwerefeldbestimmung,  bei  der  Messun- 
gen des  Abstandes  der  beiden  Satelliten  mit  einer  Genauigkeit  von  ca.  1.0/xm 
und  deren  Relativgeschwindigkeiten  mit  etwa  1  ^  gemessen  werden.  Die  Ver- 
arbeitung solcher  Daten,  die  zudem  in  großer  zeitlicher  Dichte  anfallen,  führte 
auf  die  Frage,  ob  u.a.  die  Bahnen  genügend  genau  dargestellt  werden  können. 
Abb.  1.1  zeigt  das  Ergebnis  einer  numerischen  Simulation  der  Bahnen,  ausge- 
führt mit  verschiedenen  Integrationsverfahren.  Es  zeigte  sich,  dass  das  in  der 
gängigen  Vorgehensweise  nicht  ausreichend  genau  gelingt.  Da  GRACE-Nach- 
folgemissionen  mit  deutlich  gesteigerter  Messgenauigkeit1  vorbereitet  werden, 
stellt  sich  die  Aufgabe  einer  hochgenauen  Lösung  des  Bewegungsproblems  um- 
so dringlicher. 

2.  Laser-Entfernungsmessungen  von  Bodenstationen  auf  der  Erde  zu  Reflektorein- 
heiten auf  dem  Mond  gelingen  seit  mehreren  Jahren  mit  etwa  1  cm  Genauigkeit. 
Es  besteht  die  Absicht,  diese  um  eine  Größenordnung  durch  verbesserte  Aus- 
wertungsverfahren zu  steigern.  Bei  der  Verarbeitung  der  Messdaten  muss  die 
Bewegung  des  in  das  Sonnensystem  eingebettete  Erde-Mond-Systems  in  nach- 
newtonscher  Näherung  gelöst  werden  und  zwar  für  den  Zeitraum  von  über  30 
Jahren,  in  dem  Messungen  vorliegen.  Die  Bestimmung  von  Modellparametern 
erfolgt  nach  dem  Verfahren  der  differentiellen  Korrektur  von  apriori-Werten, 
das  iterativ  durchgeführt  werden  muss.  Dabei  fallen  bei  jedem  Schritt  eine  Eph- 
emeridenrechnung  des  gesamten  Sonnensystems,  eine  Berechnung  der  partiel- 
len Ableitungen  der  testbaren  Funktionale  nach  den  Modellparametern  sowie 
eine  Ausgleichsrechnung  der  Beobachtungsgleichungen  an.  Die  Iteration  kon- 
vergiert nur,  wenn  die  partiellen  Ableitungen,  die  von  der  Genauigkeit  der  Eph- 
emeridenrechnung  abhängen,  hinreichend  genau  gerechnet  werden.  Der  Grund 

'siehe  mehr  dazu  unter  [Flechtner  12] 
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Kapitel  1:  Motivation 


liegt  darin,  dass  die  Ausgleichsrechnung  nach  sehr  flach  ausgeprägten  Minima 
suchen  muss. 


Abbildung  1.1:  Abstandsdifferenzen  verschiedener  Lösungen  über  einen  Simulations- 
zeitraum von  einem  Tag  (16  Umläufe) 


Die  vorgestellten  Beispiele  waren  Anlass,  numerische  Verfahren  für  die  in  Zu- 
kunft steigenden  Anforderungen  bei  der  Auswertung  der  Messdaten  bereitzustellen. 
Das  wird  noch  dringlicher  werden,  wenn  die  in  Entwicklung  befindlichen  optischen 
Uhren  (Stabilität2  bei  etwa  1CT17)  in  den  Messverfahren  zum  Einsatz  kommen.  Über 
die  numerische  Lösung  von  Bewegungsproblemen  hinaus  werden  künftig  alle  Schritte 
der  Datenvorverarbeitung  sowie  der  Auflösung  großer  Gleichungssysteme  auf  ausrei- 
chende Genauigkeit  zu  überprüfen  sein. 

Die  Lösung  der  anfallenden  Bewegungsprobleme  ist  dabei  eine  zentrale  Aufgabe,  die 
interdisziplinär  angegangen  werden  muss  (Abb.  1.2).  Hierzu  liefert  die  Numerische 
Mathematik  das  nötige  theoretische  Fundament  zur  Lösung  gewöhnlicher  Differen- 
tialgleichungen inklusive  verlässlicher  Standardverfahren.  Sowohl  die  Implementie- 
rung der  Lösungsfahren  als  auch  die  Rechnung  mit  multiprecision -Bibliotheken  ist 
Bestandteil  der  Fachdisziplin  Informatik.  Die  Lösung  einer  konkreten  Aufgabenstel- 
lung, wie  beispielsweise  die  Modellierung  einer  Satellitenbahn  im  Gravitationsfeld  der 
Erde,  erfordert  Fachwissen  aus  dem  Bereich  der  Himmelsmechanik  und  der  Geodäsie. 
Bei  der  Umsetzung  wurde  darauf  geachtet,  dass  auch  verwandte  Aufgabenstellungen 
anderer  Fachdisziplinen  gelöst  werden  können. 


2siehe  mehr  dazu  unter  [Rosenband08] 
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Abbildung  1.2:  Interdisziplinäre  Einordnung  der  Arbeit 


Im  folgenden  Kapitel  2  wird  zunächst  der  theoretische  Hintergrund  zur  Lösung  ge- 
wöhnlicher Differentialgleichungen  und  die  dafür  existierenden  Lösungsverfahren  vor- 
gestellt sowie  deren  Eigenschaften  anhand  einschlägiger  Beispiele  untermauert.  Dar- 
aufhin werden  in  Kapitel  3  die  Aspekte  der  Implementierung  jeweiliger  Lösungsver- 
fahren diskutiert.  In  Kapitel  4  werden  einige  muitiprecision-Bibliotheken  aufgrund 
ihres  Funktionsumfangs  und  Laufzeitverhaltens  evaluiert.  Um  allgemein  unnötig  lan- 
ge Programmlaufzeiten  zu  verhindern,  werden  in  Kapitel  5  unterschiedliche  Techniken 
zur  Verbesserung  von  Programmen  vorgestellt.  Darüber  hinaus  werden  im  Kapitel  6 
verschiedene  Methoden  zur  numerischen  Differentiation  präsentiert.  In  Kapitel  7  wird 
ein  Konzept  einer  Toolbox  zur  Lösung  gewöhnlicher  Differentialgleichungen  erarbei- 
tet und  mit  Beispielen  untermauert.  Daraufhin  werden  in  Kapitel  8  Anwendungssze- 
narien aus  dem  Bereich  der  Himmelsmechanik  und  Geodäsie  gezeigt.  Schließlich  wird 
in  Kapitel  9  ein  Ausblick  zu  weiteren  Entwicklungen  und  möglichen  zukünftigen  An- 
wendung geboten. 


Kapitel  1 :  Motivation 


Kapitel  2 

Lösung  gewöhnlicher  Differentialgleichungen 


Schwerpunkt  des  Kapitels: 

Viele  technische  und  physikalische  Vorgänge  lassen  sich  durch  gewöhnliche  Differen- 
tialgleichungen beschreiben  und  stellen  somit  ein  mathematisches  Grundgerüst  des  je- 
weils untersuchten  Problems  dar.  Dadurch  wird  beispielsweise  die  zeitliche  und  räum- 
liche Veränderung  eines  Objekts  inklusive  aller  Einflussgrößen  und  Störbeschleuni- 
gungen im  Raum  beschrieben.  In  diesem  Abschnitt  werden  verschiedene  Lösungs- 
verfahren (Integratoren)  gewöhnlicher  Differentialgleichungen  vorgestellt  und  deren 
theoretischer  Hintergrund  beleuchtet.  Diese  werden  schließlich  hinsichtlich  ihrer  Ab- 
arbeitungsgeschwindigkeit und  ihres  Fehlerhaushalts  anhand  praktischer  Beispiele  un- 
tersucht und  bewertet. 
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Kapitel  2:  Lösung  gewöhnlicher  Differentialgleichungen 


2.1  Fehlernormen 

Um  die  Güte  von  Ergebnissen  anhand  von  Referenzlösungen  im  zeitlichen  Verlauf  be- 
urteilen zu  können,  werden  einige  verschiedene  Fehlernormen  benötigt.  Diese  werden 
im  Folgenden  definiert,  um  später  darauf  zurückgreifen  zu  können. 

2.1.1    Absoluter  Fehler 

Der  absolute  Fehler  entspricht  der  tatsächlichen  Abweichung  zwischen  gemessenen1 
Wert  Y(to)  und  dem  wahren  Wert  y(to)  zum  Zeitpunkt  to.  Damit  kann  der  absolute 
Fehler  ea(to)  definiert  werden  durch: 

ea(t0)  =  Y(t0)-y(t0)  (2.1.1) 

In  Abb.  2.1  ist  dieser  Zusammenhang  illustriert.  Dieses  Fehlermaß  trägt  stets  die  Ein- 
heit des  untersuchten  Werts. 


t 


t0 

Abbildung  2. 1 :  Absoluter  Fehler 


2.1.2  Relativer  Fehler 

Der  relative  Fehler  er(to)  bezeichnet  den  prozentualen  Anteil  der  Abweichung  des 
gemessenen  Werts  Y(to)  vom  wahren  Wert  y(to)  zum  Zeitpunkt  to-  Dieser  lässt  sich 
formell  beschreiben  durch: 

eo(t0)     y (to)  -  y(t0) 
eH*0j  =         \  =   TT-,   (2-1.2) 

2.1.3  Kumulativer  Fehler 

Beim  kumulativen  Fehler  €k(ti)  werden  die  jeweils  gemessenen  Fehlergrößen  e(tj)  mit 
i  G  N  aufsummiert.  Dadurch  steht  zu  jedem  Zeitpunkt  tj  das  jeweilige  Fehlerbudget 
fest.  Somit  kann  das  Anwachsen  des  Fehlers  über  der  Zeit  sichtbar  gemacht  werden 
und  ist  wie  folgt  definiert: 

3 
i=Q 


'in  dieser  Arbeit  wird  nur  in  wenigen  Fällen  mit  gemessenen  Werten  gearbeitet.  Meistens  werden 
berechnete  bzw.  simulierte  Daten  miteinander  verglichen. 


2.2  Fehler  arten 
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2.1.3.1    Kumulativer  absoluter  Fehler 

Der  kumulative  absolute  Fehler  eka(U)  bezeichnet  die  Fehlersumme  des  absoluten 
Fehlers  ea  bis  zum  Zeitpunkt  ij. 


2.1.3.2    Kumulativer  relativer  Fehler 

Der  kumulative  absolute  Fehler  ej.r  (ij)  bezeichnet  die  Fehlersumme  des  relativen  Feh- 
lers er  bis  zum  Zeitpunkt  ij. 


2.1.4    Gewichtete  /2-Norm 

In  vielen  der  folgenden  Problemstellungen  liegen  die  Ergebnisse  in  kartesischen  Koor- 
dinaten x,  y,  z  vor.  Um  die  Qualität  der  jeweiligen  Messergebnisse  beurteilen  zu  kön- 
nen wäre  es  prinzipiell  möglich,  diese  komponentenweise  mit  der  analytischen  Lösung 
zu  vergleichen.  Da  dies  aufgrund  der  vielen  Vergleiche  zu  unübersichtlich  werden  wür- 
de, kann  eine  gewichtete  /2-Norm  0  gewählt  werden.  Diese  liefert  ein  kompakteres 
Fehlermaß  und  ist  wie  folgt  definiert: 


(4J2  +  (4V)2  +  (4 


y(U)x2  +  y(ti)y2  +  y(u)2 


i=0 
mit 

4  =  Y(u)x  -  y(ti)x 


\2 


Av=Y(ti)y-y(ti)y  (2.1.4) 


4  =  Y{u)t  -  y{U)z 
Die  /2-Norm  kann  als  relative  Ortsabweichung  betrachtet  werden. 

2.1.5    Mittlerer  Fehler 

Oft  ist  es  hilfreich,  einer  Simulation  eine  Fehlerkennzahl  zuordnen  zu  können.  Dies 
kann  mit  Hilfe  des  mittleren  Fehlers  e  bewerkstelligt  werden,  der  wie  folgt  definiert 
ist: 


1  /  1 

e  =  =  \/ -<*(*«)  (2-1.5) 

m  ^-^  V  m 

i=i 

Wobei  m  die  Anzahl  der  Fehlerterme  darstellt  und  ep.  der  kumulative  Fehler  ist.  Der 
Fehlermittelwert  könnte  auch  als  mittlerer,  kumulativer  Fehler  bezeichnet  werden. 


2.2  Fehlerarten 

Nachdem  im  vorigen  Abschnitt  die  Fehlermaße  zur  Beurteilung  der  Güte  von  Messwer- 
ten definiert  wurden,  ist  es  weiter  erforderlich,  den  Gesamtfehler  eg,  welcher  aus  dem 
Vergleich  zwischen  Mess  -  und  wahrem  Wert  resultiert,  nach  verschiedenen  Fehlerar- 
ten aufzuschlüsseln.  Prinzipiell  kann  der  Gesamtfehler  in  folgende  Teile  zerlegt  wer- 
den: 
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•  Eingangsfehler  eeingang 

Bei  dieser  Fehlerart  handelt  es  sich  um  einen  kaum  vermeidbaren  Fehler,  dessen 
Größenordnung  aber  bekannt  sein  sollte,  da  dieser  die  anfängliche  Genauigkeit 
festlegt.  Besonders  bei  der  Integration  von  Satellitenbahnen  sind  die  Anfangs- 
werte nur  mit  einer  bestimmten  dezimalen  Genauigkeit  bekannt.  Diese  Unsi- 
cherheit wird  als  Eingangsfehler  bezeichnet. 

•  Verarbeitungsfehler  bzw.  Initialisierungsfehler 

-  Rundungsfehler  erci 

Der  Rundungsfehler  kann  an  verschiedener  Stelle  auftreten.  Einerseits  bei 
der  Initialisierung  einer  Variablen  mit  einer  Zahl,  deren  Wert  nicht  auf  die 
interne  Darstellung  abgebildet  werden  kann  (implizite  Rundung).  Anderer- 
seits bei  der  Verarbeitung  zweier  Gleitkommazahlen,  bei  denen  am  Ende 
der  eigentlichen  Operation  (z.B.  Addition)  das  Ergebnis  auf  die  interne 
Darstellung  abgebildet  wird  und  ebenfalls  gerundet  wird. 

-  Diskretisierungsfehler  (Verfahrensfehler) 

Bei  dieser  Fehlerart  wird  das  Ergebnis  aufgrund  der  Güte  des  jeweils  ver- 
wendeten Verfahrens  mehr  oder  weniger  verschlechtert.  Falls  beispielswei- 
se die  Auswertung  einer  Taylorreihe  bei  einer  bestimmten  Ordnung  abge- 
brochen wird,  dann  entsteht  ein  lokaler  Diskretisierungsfehler. 

Es  ergibt  sich  folgende  formelle  Aufgliederung  des  Gesamtfehlers: 

6g  =  ^eingang  +  ^rd      ^d  (2.2.6) 

2.3    Numerische  Integrationsverfahren 

Die  Bewegung  eines  Objektes  kann  durch  Lösung  von  gewöhnlichen  Differentialglei- 
chungen dargestellt  werden.  Im  einfachsten  Fall  handelt  es  sich  hierbei  um  eine  Diffe- 
rentialgleichung n-ter  Ordnung.  Diese  können  sowohl  analytisch,  als  auch  durch  nume- 
rische Integration  der  Bewegungsgleichungen  bestimmt  werden.  Derartige  Lösungs- 
verfahren werden  eingesetzt,  falls  keine  analytische  Lösung  vorhanden  oder  diese  zu 
aufwendig  zu  lösen  ist.  Die  zur  numerischen  Integration  verwendeten  Verfahren  sind 
Standard  verfahren  aus  der  numerischen  Mathematik  zur  Lösung  von  gewöhnlichen 
Differentialgleichungssystemen  1-ter  und  2-ter  Ordnung2.  Anders  als  bei  analytischen 
Lösungen  wird  hierbei  keine  zeitkontinuierliche  Lösung  erzeugt.  Es  wird  lediglich  zu 
diskreten  Zeitpunkten  durch  Lösen  eines  Ersatzproblems3  ein  Resultat  bestimmt.  Mit 
anderen  Worten,  diese  Verfahren  erzeugen  eine  Wertetabelle  mit  Stützstellen,  welche 
bestimmten  Zeitpunkten  zugeordnet  sind.  Wird  eine  Lösung  zwischen  den  errechne- 
ten Stützstellen  benötigt,  so  kann  mittels  Interpolation  der  jeweilige  Zwischenwert 
bestimmt  werden. 

2.3.1    Gewöhnliche  Differentialgleichungen 

[dgl]    Differential-  Eine  gewöhnliche  Differentialgleichung  DGL  ist  eine  Funktion,  bei  der  neben  der  ge- 

gleichung   

2  siehe  dazu  [KönigCß] 

3siehe  mehr  dazu  in  [Schneider99],  Seite  1043 
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suchten  Funktion,  auch  Differentialquotienten  der  Funktion  auftreten.  Je  nachdem, 
ob  nur  Ableitungen  einer  Funktion  oder  partielle  Ableitungen  mehrerer  Variablen  zu- 
gleich auftreten,  wird  zwischen  gewöhnlichen  und  partiellen  DGL  unterschieden.  Der 
Schwerpunkt  dieser  Arbeit  liegt  auf  ausschließlich  auf  gewöhnlichen  DGL. 
Sei  /  eine  stetige  Funktion.  So  ist 

f(x,y,y',y",...,yW)  =  0  (2.3.7) 

ein  gewöhnliches  Differentialgleichungssystem  mit  n-ter  Ordnung,  wobei  y^>  die  ri- 
te Ableitung  ist.  Im  Allgemeinen  besitzt  dieses  System  unendlich  viele  Lösungen4. 
Eine  spezielle  Lösung  wird  durch  die  Wahl  der  Anfangsbedingungen  festgelegt.  Kann 
eine  DGL  außerdem  nach  der  höchsten  Ableitung  aufgelöst  werden,  so  wird  diese  als 
explizite  DGL  bezeichnet.  Sie  hat  folgende  Form: 

yW  =  f(x,y,y',y",...Jn-V)  (2.3.8) 


Die  hier  untersuchten  Lösungs verfahren  können  ausschließlich  DGL  1-ter  oder  2-ter 
Ordnung  lösen.  Liegt  eine  DGL  höherer  Ordnung  vor,  so  kann  diese  stets  auf  ein  Sy- 
stem erster  Ordnung  zurückgeführt  werden.  Um  den  Einsatz  gewöhnlicher  Differen- 
tialgleichungen besser  zu  veranschaulichen,  wird  folgendes  Beispiel  aus  [HuckleOö] 
(Seite  280  und  281)  entlehnt. 

Beispiel  2.1  für  „Freier  Fall  im  konstanten  Schwerefeld" 

Ein  Körper  wird  aus  der  Höhe  ho  zum  Zeitpunkt  to  —  0  losgelassen  und  unter  dem  Ein- 
fluss  der  konstanten  Erdanziehung  —g  nach  unten  beschleunigt.  Zum  Zeitpunkt  des  Loslassens 
ist  die  Anfangsgeschwindigkeit  gerade  vq  —  0.  Wir  wollen  sowohl  die  momentane  Höhe  h(t) 
als  auch  die  Geschwindigkeit  v(t)  in  Abhängigkeit  von  der  Zeit  t  bestimmen. 
Aus  der  Physik  kennen  wir  die  fundamentalen  Beziehungen  zwischen  der  Beschleunigung 
a(t)  =  —g,  der  Geschwindigkeit  v  (t)  und  der  Höhe  h(t)  als  System  von  gewöhnlichen  Differential- 
gleichungen. 

v(t)  =  h(t)  =  ^  (2.3.9) 
dv  d2h 

a{t)=v{t)  =  -  =  —  =h{t)  (2.3.10) 

Die  Geschwindigkeit  v(t)  bestimmen  wir  durch  Integration  von  2.3.9  mit  der  bekannten  Be- 
schleunigung a(t)  =  —g 

v(t)=  [  a(T)dT  =  -gf  dr  =  -gt  (2.3.11) 

Die  Geschwindigkeit  v(t)  steigt  somit  proportional  mit  der  verstrichenen  Fallzeit  t  an.  Die 
Proportionalitätskonstante  entspricht  der  konstanten  Beschleunigung  —g.  Um  die  Höhe  h(t) 
zu  bestimmen,  integrieren  wir  2.3.9  und  erhalten: 

h(t)  =  h0  +  [  v(r)dT  =  h0  -  g  [  rdr  =  h0  -  \gt2 .  (2.3.12) 
Jt0  Ja  2 


siehe  dazu  [Burlisch05] 
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Somit  haben  wir  die  Höhe  h(t)  und  die  Geschwindigkeit  v(t)  in  Abhängigkeit  der  Zeit  t  berech- 
net und  können  z.B.  die  Aufschlagszeit  t\  und  die  entsprechende  Auf  Schlagsgeschwindigkeit  V\ 
auf  den  Boden  aus  der  Bedingung  h(t\)  =  0  ermitteln: 


(2.3.13) 


Vl  =  -^2h^g  (2.3.14) 

Das  aufgeführte  Beispiel  ist  vergleichsweise  einfach  und  durch  zweifache  Integration  zu  lösen, 
weil  die  auftretende  Differentialgleichung  nur  eine  Funktion  der  unabhängigen  Variablen  t 
und  nicht  von  den  abhängigen  Variablen  h(t)  oder  v(t)  ist. 

Die  Lösung  einer  Differentialgleichung  besteht  im  Allgemeinen  aus  einer  Vielzahl 
von  Lösungen.  Im  gezeigten  Beispiel  wurde  lediglich  eine  bestimme  Lösung  heraus- 
gegriffen, indem  bestimmte  Anfangswerte  gewählt  wurden. 


2.3.2    Anfangswertprobleme  [AWP] 

[AB]  Anfangsbedin-  Werden  einer  gewöhnlichen  Differentialgleichung  zusätzliche  AB  zugeordnet,  so  wird 
gung  dies  als  Anfangswertproblem  bezeichnet.  Die  Anfangsbedingungen  (y(t))  sind  wie- 

derum einem  bestimmten  Zeitpunkt  t  zugeordnet  und  haben  die  Form: 

y  =  f(t,y)  =  f(t,y(t))  (2.3.15) 

mit  den  AB 

y(t0)  =  y0  (2.3.16) 

Der  Zeitraum,  für  den  eine  Lösung  eines  bestimmten  AWPs  berechnet  wird,  nennt  man 
Integrationszeitraum. 


2.3.3    Einteilung  der  numerischen  Lösungsverfahren 

Bei  der  numerischen  Integration  einer  DGL  wird  eine  Wertetabelle  errechnet.  Die- 
se besteht  aus  Wertepaaren  (xj,  Yj),  wobei  i  €  /  ist.  Die  berechneten  Werte  werden 
auch  als  Stützstellen  bezeichnet  und  beschreiben  beispielsweise  die  Bewegung  eines 
Objekts  im  Raum.  Berechnet  das  numerische  Integrationsverfahren  Stützstellen  mit 
äquidistantem  Abstand,  so  wird  eine  konstante  Schrittweite  (h  =  const)  verwendet. 
Die  Abszissen  sind  wie  folgt  definiert: 

Xi  =  xq  +  ih  (2.3 .17) 

wobei  i  =  0, 1, n;  i  G  I  mit  I  =  [xo,  xn] 
und  h  =  Xi+i  —  Xi  >  0 

Die  numerisch  bestimmten  Wertepaare  (xj,  Yj)  stellen  lediglich  eine  Approxima- 
tion des  tatsächlichen  Funktionswerts  dar.  Wie  genau  der  approximierte  Wert  an  den 
wahren  Wert  angenähert  ist,  hängt  vom  Integrationsverfahren,  dem  verwendeten  Da- 
tentyp und  der  Größe  des  Eingangsfehlers  ab.  Aus  diesem  Grund  muss  Folgendes  be- 
achtet werden: 


2.3  Numerische  Integrationsverfahren 
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(*o.y(*o)) 


Abbildung  2.2:  Ermittlung  der  Näherungslösung  durch  numerische  Integration  mit 
konstanter  Schrittweite 


Yi  :=  Y(xi)  «  y(xi)  =:  yi 


approximiert 


exakt 


Yi  steht  für  den  numerisch  angenäherten  Funktionswert  und  j/j  für  den  exakten  Funk- 
tionswert an  der  Stelle  Xj. 

Durch  formale  Integration  über  I  =  [xq,  xn]  ergibt  sich  folgende  Integralgleichung: 

y(t)dt  =  y{xn)  -  y(x0)  =  \     f(t,y(t))dt  (2.3.18) 

(2.3.19) 


.Co 


y(x)  =  y(x0)+  /  f(t,y(t))dt 

Jxo 

Es  soll  die  Stützstelle  x\e  I  des  AWP  berechnet  werden.  Wird  somit  ein  einzelner 
Integrationsschritt  betrachtet,  so  entsteht  folgender  Ausdruck: 


y(xi)  =  y(x0)+  /  f(t,y(t))dt 

Jx0 


(2.3.20) 


2.3.3.1    Explizite  Lösungs  verfahren 


Bei  den  expliziten  Verfahren  werden  zur  Berechnung  ausschließlich  zeitlich  zurück- 
liegende Werte  verwendet.  Diese  Verfahren  finden  beispielsweise  im  Prädiktor-Schritt 
der  Prädiktor-Korrektor- Verfahren  ihre  Verwendung. 

2.3.3.2    Implizite  Lösungsverfahren 

Die  impliziten  Lösungsverfahren  verwenden  sowohl  zeitlich  zurückliegende,  als  auch 
vorhergesagte  Werte.  Diese  Verfahren  werden  als  Korrektor  in  Prädiktor-Korrektor- 
Verfahren  eingesetzt. 


2.3.3.3  Einschrittverfahren 


Die  Einschrittverfahren  benötigen  zur  Berechnung  eines  weiteren  approximierten  Wer- 
tes Yi+i  ausschließlich  einen  vorherigen  Wert  Y{.  Weitere  vorherige  Werte  Yj_2  wer- 
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den  dabei  nicht  in  Betracht  gezogen.  Ein  Einschrittverfahren  wird  durch  folgende  Re- 
kursion beschrieben: 

Y(xi+1)  =  y(xi)  +  h$(xi,  y(xi),  h,  f)  (2.3.21) 

Die  Funktion  $  wird  als  Inkrementfunktion  bezeichnet.  Ist  die  Inkrementfunktion  un- 
abhängig von  der  Schrittweite  h,  so  ist  es  ein  explizites  Einschrittverfahren.  Ist  die 
Inkrementfunktion  von  h  abhängig  (<£(/i)),  so  ist  das  Verfahren  implizit.  Bekann- 
te Einschrittverfahren  sind  das  klassische  Runge-Kutta- Verfahren,  das  Euler-Cauchy- 
Verfahren  und  das  Verfahren  von  Heun.  Hierbei  wird  eine  Taylorreihe  mit  einer  be- 
stimmten Ordnung  zur  Extrapolation  verwendet. 

2.3.3.4  Mehrschrittverfahren 

Bei  den  Mehrschrittverfahren  werden  zur  Berechnung  eines  Funktionswerts  Yj+i  ei- 
ne Menge  z  >  1  vorangegangener  Funktionswerte  Y„z,  Yj_2+i, Yj_i,  Yj  in  Be- 
tracht gezogen.  Bekannte  Vertreter  aus  der  Klasse  der  Mehrschrittverfahren  stellen  die 
Integrationsverfahren  von  Shampine-Gordon,  Störmer-Cowell  und  Burlisch-Stör  dar. 
Diese  Verfahren  benötigen  zur  Berechnung  gleichmäßig  verteilte  Zeitschritte.  Pro  Inte- 

[dgl]    Differential-  grationsschritt  sind  zwei  Aufrufe  der  DGL  nötig.  Der  erste  Schritt  wird  als  Prädiktor- 

gieichung  Schritt  und  der  zweite  als  Korrektor-Schritt  bezeichnet. 

Der  Prädiktor-Schritt  hat  folgende  Form5: 

n 

Vi+i  =Vi  +  h^2  amf(h  *  )  (2.3.22) 

m=l 

Die  am-Koeffizienten  des  Prädiktor-Schritts  werden  wie  folgt  ermittelt: 

f{x)  =  a0  +  a\x  +  a2x2  +  ...  +  anxn 
fix)  =  a\  +  2a,2X  +  ...  +  nanxn~l 
Wird  /  für  xq  =  0  und  x\  =  \  ausgewertet,  so  ist 

/(0)  =  a0 

/(l)  =  a0  +  a\  +  ...  +  an 


(2.3.23) 


(2.3.24) 


Somit  ist  /(l)  =  f(Ö)  +  df  mit  df  =  a\  + ...  +  an.  Für  die  zurückliegenden  Zeitpunkte 
gilt  Folgendes: 

f\0)  =  oi 

f'il)  =ai  -2a2  +  3a3  +  ... 

/'(2)  =  ai-4a2  +  12o3  +  ...  (2.3.25) 

2   ,         ,  „„   /  ™\n-l 


/'(— m)  =  a\  +  2a2i—m)  +  Sa^i—m)  +  ...  +  na 


-m) 


Werden  die  Koeffizienten  in  Form  einer  Matrixschreibweise  dargestellt,  so  gilt 

/'  =  Ma 
a  =  M~Lf 


(2.3.26) 


5  siehe  dazu  auch  [Graber  10],  Seite  61 
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Somit  wird  df  aus  der  Summe  der  Koeffizienten  von  a  gebildet. 

df  =  aTI  =  {ff  {MTy1I  (2.3.27) 

V  v  ' 

Olm 

Die  am  -  Koeffizienten  werden  durch  {MTflI  bestimmt.  Der  Korrektor-Schritt 

verwendet  den  vorhergesagten  Zustand,  um  die  Gleichung  auszuwerten  und  zu  ver- 
bessern. 

n 

Vi+i  =  Vi  +  h^2  ßmf(h  *  xi+1-m,  yi+i-m)  (2.3.28) 

m=0 

Dabei  enthält  ßm  die  Koeffizienten  der  Korrekturwerte.  Die  Vorgehensweise  ist  dabei 
analog  zu  der  des  Prädiktor-Schritts.  Es  wird  lediglich  der  Zeitpunkt  Xi+i  mit  einbe- 
zogen. 


2.3.3.5    Erweiterung  der  Prädiktor-Korrektor- Verfahren  mit  adaptiver  Schritt- 
weitensteuerung [SWS] 

Ein  Prädiktor-Korrektor- Verfahren  kann  zusätzlich  mit  einer  adaptiven  Schrittweiten- 
steuerung ausgestattet  werden.  Viele  der  gängigen  Standardverfahren  sind  mit  dieser 
Funktionalität  ausgestattet.  Dabei  wird  für  jeden  Integrationsschritt  die  Schrittweite  so  [SWS]  Schrittweiten- 
angepasst,  dass  der  Diskretisierungsfehler  möglichst  minimal  wird  (siehe  dazu  2.6.1  steuemng 
auf  Seite  44).  Dabei  ist  zu  beachten,  dass  bei  allen  Verfahren  lediglich  der  lokale  Dis- 
kretisierungsfehler e\  in  Betracht  gezogen  wird  und  nicht  der  Gesamtfehler  eg. 


2.3.4    Theorie  der  numerischen  Lösungsverfahren 

In  den  folgenden  Unterpunkten  wird  auf  die  Lösungsverfahren  eingegangen,  welche 
im  Rahmen  dieser  Arbeit  verwendet  wurden.  Dabei  werden  zuerst  die  klassischen 
Runge-Kutta- Verfahren,  dann  verallgemeinerte  Runge-Kutta- Verfahren  und  schließ- 
lich Verfahren  mit  adaptiver  Schrittweitensteuerung  betrachtet.  Ferner  wird  auch  auf 
alternative  Ansätze,  wie  den  Potenzreihenintegrator  und  die  Taylorreihenmethode  ein- 
gegangen. Zuletzt  wird  die  Quadratur  als  weitere  alternative  Lösungsmethode  vorge- 
stellt. 


2.3.4.1    Das  Runge-Kutta- Verfahren  2.0rdnung  [RK2] 

Das  Runge-Kutta- Verfahren  2.  Ordnung  ist  ein  Einschrittverfahren  ohne  automatische 
Schritt weitensteuerung.  Ist  der  Funktionswert  y{xi)  =  yi  als  AB  gegeben,  so  kann  [RK2]  Runge-Kutta  2. 

Y(xi+\)  =  Yi+i  durch  Lösung  folgender  Gleichung  mit  Hilfe  des  Runge-Kutta-  °rdmmg 
Verfahrens  bestimmt  werden: 

Yi+1  =  Vi  +  hk2  +  0(/i3)  (2.3.29) 

wobei 

ki  =  hf(xi,yi) 

,  L*,  h  ^  (2"3-30) 

k2  =  hf(Xi  +  -,yt  +  —) 
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Hierbei  ist  h  die  gewählte  Schrittweite  und  0(h3)  entspricht  der  Konsistenzordnung. 
Für  einen  Integrationsschritt  benötigt  dieses  Verfahren  2  Auswertungen  der  Differen- 
tialgleichung, 3  Additionen,  3  Multiplikationen  und  2  Divisionen. 


2.3.4.2    Das  Runge-Kutta- Verfahren  3.0rdnung  [RK3] 

Das  Runge-Kutta- Verfahren  3. Ordnung  ist  ein  Einschrittverfahren  ohne  automatische 
Schrittweitensteuerung.  Ist  der  Funktionswert  y{xi)  =  t/i  als  AB  gegeben,  so  kann 
Y(xi+i)  =  Yi+\  durch  Lösung  folgender  Gleichung  mit  Hilfe  des  Runge-Kutta- 
Verfahrens  3. Ordnung  bestimmt  werden: 

Yi+1  =yi  +  ^(kl+  Ak2  +  k3)  +  0{hA)  (2.3.31) 

wobei 

h  =  hf(xi,yi) 

k2  =  hf{xi  +  ^yi+k±)  (2.3.32) 
h  =  hf(xi  +  h,yi  +  k2) 

Hierbei  ist  h  die  gewählte  Schrittweite  und  0(/i4)  entspricht  der  Konsistenzordnung. 
Für  einen  Integrationsschritt  benötigt  dieses  Verfahren  3  Auswertungen  der  Differen- 
tialgleichung, 7  Additionen,  4  Multiplikationen  und  3  Divisionen. 


[RK3]  Runge  Kutta  3. 
Ordnung 


2.3.4.3    Das  Runge-Kutta- Verfahren  4.0rdnung  [RK4] 

Das  Runge-Kutta- Verfahren  4.  Ordnung  ist  ein  Einschrittverfahren  ohne  automatische 
[RK4]  Runge  Kutta  4.  Schrittweitensteuerung.  Ist  der  Funktionswert  y{xi)  =  yi  als  AB  gegeben,  so  kann 
°rdnung  Y(xi+i)  =  Yi+i  mit  dem  Runge-Kutta- Verfahren  bestimmt  werden: 

Yi+1  =  Vi  +  ^  (fci  +  2k2  +  2k3  +  fc4)  +  0(h5)  (2.3.33) 

h  =  hf(xi,yi) 

k2  =  hf(xi  +  ^,yi  +  ^) 

f         ,  (2.3.34) 

,  ,  ,/  n  k2. 
h  =  hf{xi  +  -,yi  +  —) 

ki  =  hf(xi  +  h,yi  +  k3) 

Dabei  ist  h  die  Integrationsschrittweite  und  0(h5)  stellt  die  Konsistenzordnung  des 
Verfahrens  dar.  Für  einen  Integrationsschritt  benötigt  dieses  Verfahren  4  Auswertungen 
der  Differentialgleichung,  10  Additionen,  7  Multiplikationen  und  5  Divisionen. 


2.3.4.4    Das  Runge-Kutta- Verfahren  N.Ordnung  [RKN] 

Wie  aus  den  bereits  erwähnten  RK- Verfahren  unterschiedlicher  Ordnung  ersichtlich 
wird,  gibt  es  eine  allgemeine,  formale  Darstellung  für  explizite  Runge-Kutta- Verfahren 
N.Ordnung.  Diese  hat  folgende  Gestalt: 
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R 


yi+i  =  yi  +         °rkr  (2.3.35) 


r=l 


mit  den  jeweiligen  kr 


h  =  f(xi,yi) 

k2  =  f(xi  +  ha2,  m  +  hb2iki) 

(2.3.36) 


n— l 


K  =  f{xi  +  han,  yi  +  h^2  bnSks) 


s=l 


Die  Gleichung  2.3.35  gibt  dabei  die  Annäherung  eines  Integrationsschritts  an.  Die  Pa- 
rameter eines  RK- Verfahrens  einer  bestimmten  Ordnung  werden  ermittelt,  indem  ihre 
formelmäßige  Darstellung  einer  Taylor- Approximation  derselben  Ordnung  gegenüber- 
gestellt wird. 


R    jr  Fl 

E  -^rf{r~1]{^y(x))  +  o(hn)  ±  J2crkr 

r=l  r=l 

Taylor— Approximation  RK— Verfahren 


(2.3.37) 


Die  freien  Parameter  bns ,  und  cr  können  aus  dem  Vergleich  der  Runge-Kutta-Formel 
mit  der  jeweiligen  Taylor-Approximation  konstruiert  werden.  Bei  dieser  Vorgehens- 
weise kann  es  vorkommen,  dass  einige  Parameter  unbestimmt  bleiben.  Aus  diesem 
Grund  gibt  es  in  der  Literatur  für  bestimmte  Ordnungen  unterschiedliche  Sätze  von 
Parametern.  Es  gibt  prinzipiell  zwei  verschiedene  Arten  von  Runge-Kutta-Methoden. 
Die  expliziten  Verfahren,  welche  nur  von  den  Koeffizienten  ki,...,kn  abhängen  und 
die  impliziten  Verfahren,  die  nur  iterativ  gelöst  werden  können.  Um  die  hier  dargestell- 
te allgemeine  Form  der  Parameterbestimmung  besser  zu  veranschaulichen,  sollen  an 
folgendem  Beispiel  die  Parameter  des  expliziten  RK2- Verfahrens  berechnet  werden. 
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Beispiel  2.2  „Bestimmung  der  freien  Parameter  des  expliziten  RK2-Verfahrens" 

Im  ersten  Schritt  soll  die  RK-Formelfilr  den  Fall  N  =  2  ausgearbeitet  werden. 

Cifci  +  c2k2  =  c1f(xl,  yi)  +  c2f(xi  +  ha2,  Vi  +  hb21f{xu  y,)) 

=  c1f(xuyi)  +  c2[f{xl,yi)  +  a2hf(xi,yi)  +  b2ihf(xi,yi)dyf(xi,yi)] 
=  (ci  +c2)f{xi,yi)  +  h[c2a2dxf(xl,yi)  +  c2b21f(xi,yi)dvf(xl,yi)} 

(2.3.38) 

Hierfür  wurde  ki  =  f(xi,yi),k2  —  ,f(xi  +  ha2,yi  +  hb2iki)  und  ^^r-  —  f(xilyi)  verwendet. 
Zum  Vergleich  wird  noch  die  Taylor-Entwicklung  benötigt.  Diese  hat  folgende  Form: 

E     /(r_1)  &      =  f(x>  ^  +  f2 [dxf{x' v)  +  /(a;'  y)dyf{x> y)]  +  °{h2)  (2339) 

r=l 

Werden  nun  die  beiden  erarbeiteten  Lösungen  untereinander  geschrieben,  so  können  die  freien 
Parameter  bestimmt  werden. 

(ci  +  c2)f(xl,yi)      +h[c2a2     dxf(xi,yi)+c2b21     f{xi,yi)dvf{xi,yi)}  (2.3.40) 

f(x,y)       +\[  dxf(x,y)+  f(x,y)dyf(x,y)}  (2.3.41) 

Aus  dem  Vergleich  können  Werte  für  die  Parameterkombinationen  abgelesen  werden: 

c\  +  c2  =  1 

1  (2.3.42) 

c2a2  =  c2b2i  =  - 

Daraus  können  die  Werte  der  freien  Parameter  bestimmt  werden:  c\  =  0,  c2  =  1,  a2  =  b2\  = 
\.  Werden  diese  Parameter  verwendet,  dann  ergibt  dies  folgende  formelmäßige  Darstellung: 

ki  =  f{xi,yi) 

k2  =  f(xi  +  ^,yi+f^k1)  (2.3.43) 
Yi+i  =Vi  +  hk2 

Die  formelmäßige  Darstellung  entspricht  exakt  der  Definition  des  RK2-Verfahrens. 

Im  Rahmen  dieser  Arbeit  wurden  außerdem  das  explizite  RK- Verfahren  8.-  und 
lO.Ordnung  implementiert.  Deren  formelmäßige  Darstellung  unterliegt  derselben  Theo- 
rie wie  die  Verfahren  niedriger  Ordnung,  welche  bereits  erwähnt  wurden.  Sie  besitzen 
jedoch  eine  höhere  Fehlerordnung  und  benötigen  entsprechend  ihrer  umfangreicheren 
Implementierung  mehr  Rechenoperationen  für  einen  Integrationsschritt. 

2.3.4.5    Das  Runge-Kutta-Fehlberg- Verfahren  [RKF] 

Das  Runge-Kutta-Fehlberg-Verfahren  einer  bestimmten  Ordnung  ist,  verglichen  mit 
klassischen  RK- Verfahren  bei  gleicher  Ordnung,  genauer.  Dieser  Zuwachs  an  Genau- 
igkeit wird  mit  etwas  höherem  Rechenaufwand  erkauft  .  Hierbei  wird  zur  Lösung  der 
Differentialgleichung  örtliche  Steigungsinformation  ausgenutzt,  was  zu  einer  Verbes- 
serung der  lokalen  Fehlerordnung  führt.  Ferner  kann  hier  mit  relativ  geringem  Auf- 
wand eine  adaptive  Schrittweitensteuerung  eingebaut  werden.  Die  Formeln  zur  Be- 
ziehe dazu  [Jordan72],  ab  Seite  309 
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rechnung  eines  Integrationsschritts  mit  der  expliziten  RKF  (4/5. Ordnung)  haben  fol- 
gende Gestalt: 


25  ,  1408  ,  2197  ,  1, 

Yi+i  =  Vi  H  h  H  H  fe4  fe5  (2.3.44) 

i+l  -r  21g   l  -r  2565   j  -r  4      g  5 


wobei 


fei  =  hf(xi,yi) 

k2  =  hf(xi  +  +  |fei) 

3  3  9 

&3  =  h/fai  +  g/i,  yi  +  g^fei  +  7^2) 

12,  1932,       7200,       7296,  ,  (2.3.45) 

fe4  =  hf(Xi  +  -Ä>w  +  —fei  -  — fe2  +  —  fc3) 

439,        ,       3680,        845  ,  . 
h  =  hf{Xi  +  h,yi  +  —fei  -  8fe2  +  ~^jk3  -  ^7^4) 

!,  8  ,       «,       3544 ,       1859 ,       11 ,  \ 

h  =  hf(xt  +  -h,yt  -  -fei  +  2fe2  -  — fc3  +  — fc4  -  -fe5) 

Hier  wurde  ein  zusätzlicher  Term  (fe6)  berechnet,  mit  dem  ein  verbessertes  Ergebnis 
erzielt  werden  kann.  Die  Formel,  welche  den  zusätzlichen  k-Term  berücksichtigt,  hat 
folgendes  Aussehen: 

16  ,        6656  ,       28561,        9  ,        2  , 

K*  ,  =  Vi  -\  ki  H  fe3  H  fe4  fe5  H  fe6  (2.3.46) 

,+1     w     135        12825        56430        50  55 

Nun  können  die  beiden  Funktionswerte  Yj+i  und  YA :  berechnet  werden,  wobei  letzte- 
rer genauer  ist.  Dies  wird  ausgenutzt  um  die  Schrittweite  h  zu  bestimmen.  Dafür  wird 
außerdem  eine  Fehlerschranke  benötigt,  die  üblicherweise  beim  Start  der  Berechnung 
angegeben  und  hier  mit  e  bezeichnet  wird.  Daraus  berechnet  sich  die  Schrittweite  wie 
folgt: 

h  =  H         €h        M       V(Y/+1  -  Yl+i)  ^0Ah<  hmax  (2.3.47) 

wobei  hmax  die  maximal  erlaubte  Schrittweite  bezeichnet.  Diese  kann  ebenfalls  beim 
Start  der  Berechnung  angegeben  werden.  Insgesamt  benötigt  dieses  Verfahren  für  einen 
Berechnungsschritt,  inklusive  Bestimmung  der  Schrittweite,  6  Aufrufe  der  Differenti- 
algleichung, 30  Additionen,  37  Multiplikationen,  27  Divisionen  und  eine  Auswertung 
der  vierten  Wurzel.  Das  RKF- Verfahren  ist  detailliert  in  [Jordan72](ab  Seite  309)  be- 
schrieben. Dort  findet  sich  auch  ein  Hinweis  zur  Erweiterung  des  RKF- Verfahrens  für 
höhere  Ordnungen.  Dieses  Verfahren  wurde  nicht  im  Rahmen  dieser  Arbeit  implemen- 
tiert. 
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2.3.4.6    Die  Modified  Midpoint  Methode  [MMID] 

Die  MMID  ist  ein  Einschrittverfahren  2.  Ordnung  ohne  adaptive  Schrittweitensteue- 
rung. Prinzipiell  kann  dieses  Verfahren  als  eigenständiges  Integrations verfahren  ange- 
sehen werden.  In  der  Praxis  wird  es  allerdings  als  Hilfsmethode  innerhalb  des  Burlisch- 
Stoer-Integrators  verwendet.  Hierbei  wird  ein  bestimmter  Integrationsschritt  der  Schritt- 
weite h  in  n  äquidistante  Zwischenschritte  h  unterteilt. 

h=-  (2.3.48) 

n 

Es  werden  stets  n  +  1  Funktionsaufrufe  pro  Integrationsschritt  benötigt.  Mit  dem  An- 
fangswert y(x),  den  jeweiligen  Zwischenwerten  Zi  und  dem  Aufruf  der  rechten  Seite 
f(x,  zm)  kann  eine  Berechnungsvorschrift  für  diese  Methode  angegeben  werden: 

zq  =  y(x) 

Z\  =  Zq  +  hf(x,  Zq) 

V       '  (2.3.49) 

Z2  =  ... 

zm+1  =  zm-i  +  2hf(x  +  mh,  zm) 
Die  Berechnung  der  approximierten  Lösung  Y(x  +  h)  an  der  Stelle  x  +  h  erfolgt  durch 

Y(x  +  h)^Yn  =  ^(zn  +  zn-!  +  hf(x  +  h,  zn)),  (2.3.50) 

wobei  für  m  =  1, 2, n—  1  gilt.  Diese  Methode  hat  eine  hilfreiche  Eigenschaft:  Wird 
die  Fehlerfunktion  in  Form  einer  Potenzreihe  in  Abhängigkeit  von  h  ausgedrückt,  so 
kann  gezeigt  werden,  dass  diese  nur  gerade  Potenzen  enthält.  Werden  nun  Schritte 
geschickt  zusammengefasst,  sodass  ein  Term  höherer  Ordnung  wegfällt,  dann  kann 
die  Genauigkeit  gleich  um  zwei  Größenordnungen  zunehmen.  In  [Press07]  (Seite  923) 
wird  ein  Beispiel7  angegeben,  das  hier  aufgegriffen  wird. 

Beispiel  2.3  „Fehlerabschätzung  zur  Modified  Midpoint  Methode" 

For  example,  suppose  n  is  even,  and  let  yn/2  denote  the  result  ofapplying  ...  with  half  as  many 
Steps,  n  — >  n/2.  Then  the  estimate 


Y(x  +  h) 


AVn     Vn'2  (2.3.51) 


is  fourth-order  accurate,  the  same  as  fourth-order  Runge-Kutta,  but  requires  only  about  1.5 
derivative  evaluations  per  step  h  instead  of  Runge-Kutta  's  four  evaluations. 

Weitere  Informationen  zur  Fehlerabschätzung  sind  in  [Press07]  ab  Seite  923  und 
in  [Press92]  ab  Seite  722  zu  finden. 

2.3.5    Symplektische  Integrationsverfahren  [SI] 

Die  Symplektischen  Integrationsverfahren  sind  eine  Untergruppe  der  geometrischen 
Lösungsverfahren  für  gewöhnliche  Differentialgleichungen.  Diese  spezielle  Form  der 


'Teilweise  wurden  die  Formelbuchstaben  angepasst. 
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numerischen  Integration  erreicht  die  Konstanz  von  Erhaltungsgrößen  wie  z.  B.  Ener- 
gie, besser  als  beispielsweise  ein  Runge-Kutta- Verfahren.  Die  SI- Verfahren  wurden 
zur  Lösung  kanonischer  Bewegungsgleichungen  konzipiert,  wobei: 

dH 
dq 

Dabei  bezeichnen  q  die  generalisierten  Koordinaten,  p  die  generalisierten  Geschwin- 
digkeiten und  H  die  Hamilton- Funktion8.  Ein  Satz  aus  Position  und  Geschwindig- 
keitswerten (p,  q)  werden  ferner  als  kanonische  Koordinaten  bezeichnet.  Information 
hierzu  sind  bei  [Schneider93]  (ab  Seite  469)  und  in  [Yoshida90]  zu  finden.  Hierin  wird 
die  Konstruktion  von  symplektischen  Integrationsverfahren  hoher  Ordnung  diskutiert 
und  Formeln  sowie  Koeffizienten  für  die  Ordnungen  4,  6  und  8  angegeben.  Diese  wur- 
den mit  Hilfe  der  Baker-Campbell-Hausdorff9  Formel  erarbeitet  und  versprechen  eine 
schnelle  rechnertechnische  Abarbeitung.  Um  die  nötigen  Koeffizienten  zu  bestimmen 
wurde  ferner  von  [Yoshida90]  ein  iteratives  Verfahren  zur  Bestimmung  der  benötig- 
ten Nullstellen  eingesetzt  (Brents-method10).  Mit  Hilfe  dieser  Methode  wurden  für  die 
6. Ordnung  drei  verschiedene  Parametersätze  (für  die  8. Ordnung  fünf)  bestimmt.  Die 
numerischen  Werte  der  Parameter  w\,  W2,  W3  der  6. Ordnung  sind  in  Tabelle  2.1  ange- 
geben. Wobei  die  verschiedenen  Lösungsvarianten  mit  A,  B  und  C  bezeichnet  werden. 


Parameter 

A 

B 

C 

Wl 

-0.117767998417887E1 

-0.213228522200144E1 

0.152886228424922E-2 

0.235573213359357 

0.4260681 87079 180E-2 

-0.214403531630539E1 

W3 

0.784513610477560 

0.14398481679767E1 

0.144778256239930E1 

Tabelle  2.1:  Parameter  des  symplektischen  Integrators  6. Ordnung 


siehe  mehr  dazu  unter  [Stephani95],  Seite  147 
'siehe  mehr  dazu  unter  [ReinschOO] 

'"siehe  mehr  dazu  unter  [Press92]  auf  Seite  454,  Kapitel  9.  Root  Finding  and  Nonlinear  Sets  ofEqua- 
tions 
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Abbildung  2.3:  Verifikation  verschiedener  Parametersätze  für  den  Symplektischen  In- 
tegrator ö.Ordnung  über  einen  Zeitraum  von  einer  Stunde 


Beispiel  2.4  „ Überprüfung  der  Stabilität  bei  Verwendung  verschiedener  Parametersätze  zur 
Integration  ö.Ordnung" 

Um  herauszufinden  welcher  Parametersatz  die  genaueste  Lösung  liefert,  soll  hier  folgende 
Aufgabenstellung  mit  jedem  der  Parametersätze  A,  und  C  aus  Tabelle  2.1  gelöst  und  einan- 
der gegenübergestellt  werden.  Als  zu  lösendes  Problem  wird  das  Keplerproblem11  verwendet, 
da  dafür  eine  analytische  Lösung  vorhanden  ist.  Es  ist  somit  zur  Verifikation  der  numerisch 
bestimmten  Lösung  geeignet. 

Um  die  Kurzzeitstabilität  der  jeweiligen  Lösung  beurteilen  zu  können,  wurden  drei  Lösungen 
einer  Keplerbahn  über  einen  Zeitraum  von  einer  Stunde  (3600  Sekunden)  berechnet.  Die  je- 
weiligen Lösungen  sind  im  kartesischen  Koordinatensystem  (x,y,  z)  angegeben  und  könnten 
prinzipiell  gegen  eine  analytische  Lösung  verglichen  werden.  Da  dies  aufgrund  der  vielen  Ver- 
gleiche zu  unübersichtlich  erscheint,  wurde  eine  gewichtete  l2-Norm  0  gewählt  (siehe  dazu 
in  Abschnitt  2.1.4  auf  Seite  7).  Hierbei  steht  k  für  die  Anzahl  der  berechneten  Ergebnisse. 
Y(ti)x  ist  das  numerisch  berechnete  Ergebnis  zum  Zeitpunkt  ti  der  x- Komponente.  Außerdem 
ist  y{ti)x  das  analytisch  berechnete  Ergebnis  zum  Zeitpunkt  ti  der  x-Komponente.  Zur  Berech- 
nung der  Lösungen  A,  und  C  wurden  jeweils  3600  Ergebnisse  berechnet  (mit  k  =  3600h 
Das  Ergebnis  des  Vergleichs  ist  in  Abbildung  2.3  dargestellt.  Bemerkenswert  ist  hier  der  signi- 
fikante Anstieg  der  0-Norm  bei  der  Lösung  des  Parametersatzes  C  über  einen  relativ  kurzen 
Berechnungszeitraum  von  einer  Stunde.  In  diesem  Fall  ist  es  zu  empfehlen,  den  Parametersatz 
für  die  Berechnung  zu  wählen,  da  dieser  den  kleinsten  Anstieg  verursacht.  Wird  der  Zeitraum 
von  einer  Stunde  auf  einen  Tag  erweitert  (k  =  86400),  dann  ändert  sich  die  Situation.  Wird 
über  einen  längeren  Zeitraum  integriert,  so  ist  der  Parametersatz  C  der  Variante  A  vorzuzie- 
hen. Zusammenfassend  ist  der  Parametersatz  für  kurze  Integrationszeiten  empfehlenswert 
und  Cfür  längere  Zeitintervalle. 
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A   

B  — 


0  10000  20000  30000  40000  50000  60000  70000  30000  90000 

Zettls] 

Abbildung  2.4:  Verifikation  verschiedener  Parametersätze  für  den  symplektischen  In- 
tegrator 6.  Ordnung  über  einen  Zeitraum  von  einem  Tag 

Die  Ergebnisse  dieser  Untersuchung  fordern  geradezu  eine  genauere  Betrachtung 
der  Parameter  8. Ordnung  hinsichtlich  Kurz  -  und  Langzeitverhalten. 

Beispiel  2.5  „Überprüfung  der  Stabilität  bei  Verwendung  verschiedener  Parametersätze  zur 
Integration  8.0rdnung" 

Im  Gegensatz  zur  6. Ordnung  wurden  von  [Yoshida90]  für  die  8. Ordnung  fünf  verschiedene 
Parametersätze  zu  je  sieben  Parametern  (w\,  ...,Wj)  erarbeitet.  Diese  sind  in  den  Tabellen  2.2 
und  2.3  aufgelistet.  Analog  zum  vorigen  Beispiel  werden  diese  mit  den  Buchstaben  A,  B,  C,  D 
und  E  bezeichnet.  In  diesem  Beispiel  wird  dieselbe  Aufgabenstellung  verwendet,  wie  im  vor- 
ausgegangenen, d.h.  es  wurde  für  jeden  der  fünf  Parametersätze  eine  Keplerbahn  berechnet 
und  das  Ergebnis  mit  der  analytischen  Lösung  verglichen.  Um  die  Kurz  -  und  Langzeitstabili- 
tät beurteilen  zu  können,  wurde  für  ersteres  wieder  ein  Integrationszeitraum  von  einer  Stunde 
(3600  Sekunden)  gewählt.  Zur  Verifikation  der  Langzeitstabilität  wurde  über  einen  Tag  inte- 
griert (86400  Sekunden).  Betrachtet  man  die  Ergebnisse  der  Simulation  (Abb.  2.5),  welche 
über  einen  Zeitraum  von  3600  Sekunden  durchgeführt  wurden,  so  liefert  der  Parametersatz 
D  das  schlechteste  Ergebnis,  wohingegen  der  Parametersatz  im  zweiten  Teil  der  Simulation 
besser  zu  sein  scheint.  Die  anderen  Parametersätze  liegen  dazwischen  und  sind  von  mehr  oder 
weniger  guter  Qualität.  Wird  nun  die  zweite,  etwas  längere  Simulation  betrachtet  (Abb.  2.6),  so 
bestätigt  sich  das  Ergebnis  aus  Abb.  2.5.  Die  Parametersätze  B  und  D  liefern  auch  über  diesen 
Zeitraum  ein  schlechteres  Ergebnis.  Mit  Abstand  der  bessere  Parametersatz  ist  A,  wobei  C  und 
E  im  Mittelfeld  liegen. 


Parameter 

A 

C 

Wl 

-0.161 582374 150097E+1 

-0.1692485877701 16E-2 

0.3 117908 124 18427E+0 

W2 

-0.244699 182370524E+1 

0.289195744315849E+1 

-0.155946803821447E+1 
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w3 

-0.7 16989419708 120E-2 

0.378039588360192E-2 

-0.167896928259640E+1 

0.244002732616735E+1 

-0.289688250328827E+1 

0.166335809963315E+1 

w5 

0.157739928123617E+0 

0.289105148970595E+1 

-0.106458714789183E+1 

0.1 820206309707 14E+1 

-0.233864815101035E+1 

0.136934946416871E+1 

Wj 

0. 10424262086999 1E+1 

0.148819229202922E+1 

0.6290306502 10433E+0 

Tabelle  2.2:  Parameter  des  symplektischen  Integrators  8. Ordnung 


Parameter 

E 

W\ 

0.102799849391985E+0 

0.22773 8 840094906E-1 

W2 

-0.196061023297549E+1 

0.252778927322839E+1 

W3 

0.193813913762276E+1 

-0.719180053552772E-1 

WA 

-0.158240635368243E+0 

0.536018921307285E-2 

W5 

-0.144485223686048E+1 

-0.204809795887393E+1 

Wq 

0.253693336566229E+0 

0.107990467703699E+0 

W-J 

0.914844246229740E+0 

0.130300165760014E+1 

Tabelle  2.3:  Parameter  des  symplektischen  Integrators  8. Ordnung 


2.5e-14 
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Abbildung  2.5:  Verifikation  verschiedener  Parametersätze  für  den  Symplektischen  In- 
tegrator 8. Ordnung  über  einen  Zeitraum  von  einer  Stunde 

Um  zu  noch  höheren  Ordnungen  vorzudringen  hat  [Yoshida90]  folgenden  Hinweis 
gegeben: 

In  order  to  obtain  Wth  order  Integrators  in  this  way,  the  next  order  ofthe  BCHformu- 
lae  becomes  necessary,  and  the  order  ofthe  simultaneous  algebraic  equations  becomes 
mach  higher. 


2.3  Numerische  Integrationsverfahren 
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Abbildung  2.6:  Verifikation  verschiedener  Parametersätze  für  den  symplektischen  In- 
tegrator 8. Ordnung  über  einen  Zeitraum  von  einem  Tag 


2.3.5.1    Das  Leap-Frog  Integrationsverfahren  [LF] 

Dieses  Einschrittverfahren12  ist  speziell  zu  Lösung  physikalischer  Bewegungsglei- 
chungen konzipiert  und  stellt  eine  Verbesserung  des  Euler- Verfahrens  dar.  Hierbei 

wird  abwechselnd  der  Ort  y(ti)  und  die  Geschwindigkeit  dyJ^+2^  =  y(i  +  f)  zu 

unterschiedlichen  Zeitpunkten  ti  und  ti+i  berechnet,  wobei  die  Schrittweite  mit  h 
bezeichnet  wird.  Bei  diesem  Verfahren  werden  auch  die  Anfangswerte  zu  unterschied- 
lichen Zeitpunkten  benötigt,  d.h.  beispielsweise  der  Ort  y(l)  und  die  Geschwindigkeit 
y(1.5)  mit  h  =  1  als  Schrittweite.  Das  Prinzip  ist  in  Abb.2.7  illustriert,  woraus  auch 
die  Namenswahl  dieses  Verfahrens  ersichtlich  wird.  Dieses  Verfahren  ist  von  zweiter 
Ordnung  und  benötigt  pro  Integrationsschritt  eine  Auswertung  der  rechten  Seite  der 
Kraftfunktion.  Die  Berechnung  eines  Integrationsschritts,  beginnend  vom  Zeitpunkt 
to  mit  einer  Schrittweite  h  =  1,  kann  formal  wie  folgt  beschrieben  werden: 

Y{tl)  =  Y{t0)  +  hY(U) 

2  (2  3  53) 

Y(t3_)  =  Y(ti)  +  hf(Y(t0),Y(ti)) 

2  2  2 

Dies  kann  weiter  verallgemeinert  werden  durch 

Y(ti+1)  =  Y(U)  +  hY(ti+i) 

2       .  (2.3.54) 

Y(ti+s)  =  Y(tt+1_)  +  hf(Y{ti),Y(ti+ß 

wobei  %  G  N  und  i  >  0  gilt.  Ein  verwandtes  Verfahren,  das  hier  noch  erwähnt  werden 
soll,  ist  das  Verlet- Verfahren.  Hierbei  handelt  es  sich  um  ein  Verfahren  4. Ordnung, 

12  siehe  mehr  dazu  unter  [Hut95]  und  [MikkolaOl] 
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welches  ebenfalls  zur  Gruppe  der  symplektischen  Integrationsverfahren  zählt.  Weitere 
Informationen  zu  diesem  Verfahren  sind  in  [Verlet67]  und  [Hairer03]  zu  finden. 

Beispiel  2.6  für  ^synchrone  Anfangs-u.  Ausgabewerte  beim  LF -Integrator" 

Wie  bereits  erwähnt,  erfordert  die  Integration  mit  dem  LF-Integrator  zeitlich  um  ^  versetzte 
Anfangswerte  für  Ort  und  Geschwindigkeit.  In  Abbildung  2.8  ( Seite  24)  wurde  die  y-Komponente 
eines  Kepler-Orbits  über  einen  kurzen  Zeitraum  von  10  Sekunden  integriert  und  dieser  in  Ort 
y(t)  und  Geschwindigkeit  v(t)  über  der  Zeit  aufgetragen.  Dieses  Verfahren  liefert,  analog  zu 
den  Anfangswerten,  auch  Stützstellen  zu  unterschiedlichen  Zeitpunkten.  Damit  nimmt  dieses 
Verfahren,  verglichen  mit  allen  anderen  hier  erwähnten  Verfahren,  eine  Sonderstellung  ein. 


Abbildung  2.8:  Integration  mit  dem  Leapfrog  Integrator 


2.3  Numerische  Integrationsverfahren 
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2.3.5.2    Das  Verfahren  von  Gauss  -  Jackson  [GJ4] 

[GJ4]  Gauss  -  Jackson 

4.  Ordnung  jjas  Gauss-Jackson- Verfahren  ist  ein  Mehrschritt-Prädiktor- Verfahren  mit  fester  Schritt- 

weite h,  welches  zur  Lösung  von  Differentialgleichungen  2.  Ordnung  konzipiert  wur- 
de. Dieses  Verfahren  ist  wie  das  Burlisch-Stoer  und  das  Shampine-Gordon- Verfahren 
nicht  selbststartend  und  benötigt  zum  Anlauf  der  Integration  eine  bestimmte  Anzahl 
von  Stützstellen  zurückliegender  Zeitpunkte  (...,  to  —  2h,  to  —  h,to,to  +  h,  to  +  2h, ...). 
Diese  Schritte  können  für  n  6  [—2,2]  und  n  €  N  kurz  als  tn  =  to  +  nh  ausge- 
drückt und  mit  i_2,  t_i,  to,  t±,  £2  geschrieben  werden.  Damit  nur  ein  Anfangswert- 
paar aus  Ort  und  Geschwindigkeit  zu  Beginn  benötigt  wird,  werden  diese  mit  Hilfe 
des  RK4-Integrators  in  einer  Initialisierungsroutine  berechnet.  Aus  diesen  Startwerten 
wird  dann  eine  Tabelle  aus  Rückwärtsdifferenzen  aufgebaut,  die  bei  jedem  Integrati- 
onsschritt aktualisiert  wird.  Weitere  Informationen  zur  Herleitung,  als  auch  Hinweise 
zur  Implementierung  des  GJ4-Integrators,  sind  in  [Berry04]  und  in  [Montenbruck05] 
(Kapitel  4.2.7)  zu  finden. 


2.3.5.3    Das  Extrapolationsverfahren  von  Burlisch  und  Stoer  [BS] 

[BS]  Burlisch  und  Sto- 

Das  BS-Verfahren  benutzt  im  Prädiktorschritt  der  Integration  das  MMID-Verfahren13,  er 
kombiniert  mit  der  Richardson  Extrapolationsmethode.  Dabei  wird  eine  vorgegebene 
Schrittweite  h  während  der  Integration  sukzessiv  in  kleinere  Schrittweiten  h  unterteilt. 
Es  werden  folgende  Unterteilungen  verwendet 

n  =  2, 4,  6,  8, 12, 16,  24,  32, (nj  =  2nj  -  2)  (2.3.55) 

Bei  jeder  Unterteilung  wird  aus  den  berechneten  Funktionswerten  ein  Polynom  ap- 
proximiert. Im  Anschluss  wird  der  verbleibende  Fehler  abgeschätzt.  Ist  dieser  größer 
als  eine  vorgegebene  Fehlerschranke,  so  wird  das  Intervall  erneut  mit  dem  nächsthö- 
heren rij  unterteilt  und  daraus  ein  weiteres  Polynom  approximiert.  Um  eine  beliebi- 
ge Verkleinerung  der  Schrittweite  h  zu  vermeiden,  wurde  eine  Obergrenze  festgelegt. 
Dieses  Verfahren  verfügt  außerdem  über  adaptive  SWS.  Dabei  wird  die  Schrittweite  [SWS]  Schrittweiten- 
h  entsprechend  der  Fehlerabschätzung  adaptiv  angepasst14.  Die  Grundidee  des  BS-  steuemng 
Verfahrens  basiert  auf  der  Kombination  von  drei  verschiedenen  Verfahren. 

1.  Die  Richardson  Extrapolation15 

Mit  dieser  Methode  wird  versucht,  mit  Hilfe  mehrerer  numerisch  berechneter 
Funktionswerte  einen  genaueren  Funktionswert  zu  einem  späteren  Zeitpunkt  zu 
extrapolieren.  Die  jeweils  benötigten  Funktionswerte  werden  anhand  der  Mo- 
dified  Midpoint  Methode  (mehr  dazu  im  Abschnitt  2.3.4.6)  ausgewählt  und  be- 
rechnet. Diese  werden  schließlich  als  Stützstellen  für  einen  numerischen  Aus- 
gleich verwendet.  Die  Methode  der  Richardson  Extrapolation  und  deren  Funk- 
tionsweise ist  ein  integraler  Bestandteil  des  BS -Integrators.  Darum  wird  im  fol- 
genden Unterpunkt  (Seite  26)  die  Funktionsweise  erläutert  und  dies  mit  einem 
Beispiel  untermauert. 


13  siehe  dazu  [Press92] 

l4siehe  dazu  [Press92]  und  [Press07] 

15  siehe  mehr  dazu  unter  [SidilO] 
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2.  Wahl  der  numerischen  Ausgleichsmethode 

Die  bereits  erwähnte  Ausgleichung  der  numerisch  bestimmten  Funktionswerte 
kann  auf  verschiedene  Art  und  Weise  erfolgen.  Es  stehen  prinzipiell  zwei  ver- 
schiedene Varianten  zur  Auswahl:  polynom  -  oder  rationaler  Ausgleich.  Hierfür 
wird  in  der  Literatur16  ersterer  bevorzugt,  die  zweite  aber  dennoch  angegeben. 
Aus  diesem  Grund  wird  in  einem  weiteren  Beispiel  deren  Eignung  untersucht. 

3.  Der  Einsatz  der  Modified  Midpoint  Methode  mit  deren  Eigenschaften 

Bei  dieser  Methode  wird  die  Fehlerfunktion  als  eine  Potenzreihe  betrachtet,  die 
nur  gerade  Potenzen  besitzt.  Indem  ein  höherer  Term  der  Fehlerfunktion  elimi- 
niert wird,  gewinnt  man  zwei  Ordnungen  an  Genauigkeit.  An  dieser  Stelle  wird 
auf  den  Abschnitt  2.3.4.6  verwiesen.  Dort  wird  dieses  Verfahren  detailliert  er- 
läutert. 

Die  Richardson  Extrapolation 

Diese  Methode  kann  verwendet  werden,  um  numerisch  bestimmte  Resultate  zu  ver- 
bessern. Durch  Anwendung  dieses  Verfahrens  kann  eine  zusätzliche  Ordnung  0(p+l) 
hinzugewonnen  werden.  Ausgegangen  wird  davon,  dass  eine  numerisch  angenäherte 
Lösung  Y(h)  in  Abhängigkeit  einer  bestimmten  Schrittweite  h  berechnet  wurde.  Dies 
kann  wie  folgt  ausgedrückt  werden: 

y  =  Y(h)  +  0(hp)  (2.3.56) 

Hierbei  ist  0{hp)  die  Fehlerordnung  in  Abhängigkeit  der  verwendeten  Schrittweite 
h.  In  vielen  Fällen  kann  dieser  Zusammenhang  um  ein  von  h  unabhängigen  Faktor  u 
erweitert  werden,  sodass  sich  folgender  erweiterter  Ausdruck  ergibt: 


y  =  Y(h)  +  uhP  +  ö(hv)  (2.3.57) 

Indem  zwei  approximierte  Lösungen  mit  unterschiedlichen  Schrittweiten  h\  und 
bestimmt  werden,  wird  versucht,  den  unabhängigen  Faktoren  u  zu  eliminieren  und 
dabei  die  Fehlerordnung  zu  gewinnen.  Sind  die  zwei  unterschiedlichen  Lösungen  be- 
rechnet, so  ergibt  sich  folgender  Zusammenhang: 

y  =  Y(h1)  +  uh{  +  ü(hl) 
y  =  Y(h2)+uhP2  +  0(hp2) 

Die  Gleichungen  können  vereinfacht  werden,  indem  das  h\  -fache  der  zweiten  Glei- 
chung vom  h%  -fachen  der  ersten  Gleichung  abgezogen  wird.  Dies  ergibt: 

y(h\  -  h\)  =  Ä|y(fei)  -  hpY(h2)  +  ö(h2p+l)  (2.3.59) 

Dies  ergibt  folgenden  Ausdruck: 

(«2  -  hl) 


l6siehe  [Press92]  auf  Seite  731  (unten) 
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wobei  das  Ergebnis  der  Richardson  Extrapolation  als  yr  bezeichnet  wird. 
Die  Schrittweiten  h%  und  /12  können  prinzipiell  frei  gewählt  werden.  Setzt  man  die 
Schrittweiten  in  Relation  und  werden  beispielsweise  für  h\  =  h  und  h%  =  \  verwen- 
det, so  kann  dieser  Ausdruck  dargestellt  werden  als: 

^(f)^)-^W+1) 

Nun  soll  die  Arbeitsweise  der  Richardson-Extrapolation  exemplarisch  dargestellt  wer- 
den: 

Beispiel  2.7  für  „Extrapolation  von  ex  mit  Hilfe  der  Richardson  Extrapolationsmethode" 

In  diesem  Beispiel  soll  die  Exponentialfunktion  ex  mit  Hilfe  der  Richardson  Extrapolations- 
methode annähernd  bestimmt  werden.  Die  Exponentialfunktion  kann  mit  folgender  Funktion 
Y{h)  näherungsweise  beschrieben  werden: 

Y(h)  =  (l  +  xh)*  (2.3.62) 

Somit  können  zwei  Lösungen,  abhängig  von  der  Schrittweite  h  berechnet  werden.  Wird  h  =  0. 1 
und  x  =  1  gewählt,  so  ergeben  sich  folgende  Zwischenergebnisse: 

Y(hi  =  0.1)  =  2.5937424601 

("2  3  63") 

Y(h2  =  0.05)  =  2.6532977051 

Durch  Einsetzen  in  die  Formel  2.3.61  mit  den  Parameter  p  =  1  ergibt  folgendes  Ergebnis  für 
Vr-' 

yr  =  2.712852950 

,  (2.3.64) 
e1  =  2.718281828 

Hierbei  wurden  die  nicht  korrekten  Dezimalstellen  rot  eingefärbt.  In  der  zweiten  Zeile  befindet 
sich  das  korrekte  Ergebnis  für  die  Exponentialfunktion  an  der  Stelle  x  =  1. 

Um  herauszufinden  welche  Ausgleichsmethode  für  einen  konkreten  Fall  geeignet 
ist  und  inwieweit  das  berechnete  Ergebnis  vom  erwarteten  abweicht,  wird  im  Folgen- 
den ein  weiteres  Experiment  durchgeführt.  Als  zusätzliche  Motivation  für  nachfolgen- 
de Überprüfung  folgt  ein  Zitat  aus  Numerical  Recipies17  zur  Wahl  der  Ausgleichsme- 
thode beim  BS-Integrator: 

Current  wisdom  favors  polynomial  extrapolation  over  rational  function  extrapolati- 
on  in  the  Bulirsch-Stoer  method.  However,  ourfeeling  is  that  this  view  is  guided  more 
by  the  kinds  of  problems  usedfor  tests  than  by  one  method  being  actually  better. 


Beispiel  2.8  für  „Untersuchung  zur  Wahl  der  Ausgleichsmethode" 

Hierfür  soll  am  Beispiel  des  ungestörten  harmonischen  Oszillators1^  überprüft  werden,  wel- 
che Ausgleichsmethode  zur  Lösung  dieser  konkreten  Aufgabe  die  bessere  ist.  Der  ungestörte 
harmonische  Oszillator  wurde  ausgewählt,  da  hierfür  sowohl  eine  gewöhnliche  Differential- 
gleichung als  auch  eine  analytische  Lösung  bereitsteht.  Somit  kann  das  Ergebnis  des  BS- 
Integrators  in  Abhängigkeit  der  verwendeten  Ausgleichsmethode  anhand  der  analytisch  be- 
rechneten Lösung  verifiziert  werden.  Die  Differentialgleichung  des  harmonischen  Oszillators 

''entnommen  aus  [Press92]  Seite  731,  unten 
l8siehe  dazu  mehr  unter  [Taylor05]  ab  Seite  163 
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ist  wie  folgt  definiert: 


d2y(t)  k 


Vit) 


(2.3.65) 


Mit  m  als  Masse,  k  als  Federkonstante  und  t  als  Zeitpunkt.  Dies  kann  wiederum  umgeformt 
werden  als 


d2y(t)        2  M 

-ÖT  =  -»  Vit), 


Die  entsprechende  analytische  Lösung  y(t)  besitzt  folgende  Form 

y(t)  ==  Acos  (wt  +  (f>),  4>  =  0 


(2.3.66) 


(2.3.67) 


Wobei  A  die  Amplitude  der  analytischen  Funktion  ist.  Wird  nun  die  Differentialgleichung  des 
harmonischen  Oszillators  mit  dem  BS-Integrator  mit  verschiedenen  Ausgleichsmethoden  ge- 
löst, so  ergibt  sich  folgender  Unterschied  ( siehe  Abb.  2.9).  Hierbei  wurde  die  y-Achse  logarith- 
misch skaliert  und  der  kumulative  absolute  Fehler  beider  Methoden  über  der  Zeit  aufgetragen. 
In  diesem  Fall  unterscheiden  sich  die  beiden  Lösungen  schon  nach  100  Sekunden  um  zwei  De- 
zimalstellen. Aus  diesem  Grund  ist  stets  zu  überprüfen,  welche  Art  der  Ausgleichsmethode  für 
den  jeweiligen  Fall  verwendet  werden  soll.  Für  diesen  Fall  zeigt  die  rationale  Methode  das 
bessere  Fehlerverhalten. 


Abbildung  2.9:  Gegenüberstellung  der  Ergebnisse  bei  Verwendung  unterschiedlicher 
Berechnungsverfahren  beim  Burlisch-Stoer-Integrator  [BS] 


2.3.5.4    Das  Mehrschrittverfahren  nach  Shampine  und  Gordon  [SG] 

[SG]  Shampine  Gor- 

don  Das  SG- Verfahren  basiert  auf  dem  Verfahren  von  Adams  Bashforth  und  Adams  Moul- 

ton.  Es  benötigt  zwei  Funktionsaufrufe,  um  einen  Integrationsschritt  durchzuführen. 


2.4  Potenzreihenintegration 
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Jeweils  einen  Prädiktor  und  einen  Korrektor-Schritt.  Es  ist  darüber  hinaus  mit  ad- 
aptiver Schrittweitensteuerung  ausgestattet.  Dazu  besitzt  das  SG- Verfahren  eine  Ord- 
nungssteuerung, die  beim  Auftreten  einer  Unstetigkeit  mit  dem  Anlaufverfahren  neu 
beginnt19. 

Die  implementierten  Verfahren  und  deren  Einordnung  nach  den  besprochenen  Kriteri- 
en sind  in  Abbildung  2.15  auf  Seite  44  dargestellt. 

2.3.6  Quadratur 

Die  Quadratur20  stellt  prinzipiell  eine  weitere  Möglichkeit  zur  Lösung  gewöhnlicher 
Differentialgleichungen  dar.  Sie  wird  oft  zur  Integration  von  Funktionen  verwendet, 
für  die  keine  analytische  Stammfunktion  vorhanden  sind.  Diese  Gruppe  von  Lösungs- 
verfahren wird  hier  nur  am  Rande  betrachtet,  es  wird  aber  dennoch  das  Prinzip  vorge- 
stellt. Hierbei  soll  das  folgende  unbestimmte  Integral  /(/)  gelöst  werden: 


mit  F(a)  und  F(b)  als  Stammfunktion.  In  vielen  Fällen  lassen  sich  keine  Stammfunk- 
tionen in  geschlossener  Form  angeben  und  man  ist  auf  Näherungsverfahren  angewie- 
sen. Bei  der  Gauß-Quadratur21  wird  die  Funktion  zunächst  an  bestimmten  Stellen  (xj 
ausgewertet.  Mit  Hilfe  dieser  Werte  und  den  Gewichten  uji  wird  auf  Basis  der  Quadra- 
turregel22: 


eine  Lösung  bestimmt.  Hierfür  wurden  in  der  Vergangenheit  eine  Vielzahl  verschiede- 
ner Methoden  entwickelt.  Beispiele  dafür  sind  außerdem  die  Gauß-Lengendre  und  die 
Gauß-Tschebyscheff-Quadratur,  als  auch  die  Romberg-Integration.  Weitere  Informa- 
tionen zu  diesen  und  weiteren  Varianten  findet  man  in  [Press07],  [Bronstein08]  aber 
auch  in  [Deuflhard08]  (ab  Seite  294). 

2.4  Potenzreihenintegration 

Die  Potenzreihenintegration  stellt  ein  alternatives  Werkzeug  zur  Lösung  gewöhnlicher 
Differentialgleichungen  dar.  Im  Gegensatz  zu  den  in  Abschnitt  2.3  beschriebenen  nu- 
merischen Integrationsverfahren  wird  bei  der  Potenzreihenintegration  während  eines 

"siehe  dazu  [Montenbruck05] 
20siehe  mehr  dazu  unter  [Bronstein08] 

21  Die  entsprechenden  Funktionen  zur  Gauß-Quadratur  wurden  im  Rahmen  dieser  Arbeit  implemen- 
tiert und  durch  Kontrollrechnungen  mit  den  Ergebnissen  von  Herrn  Prof.  Ilk  (Universität  Bonn)  Fortran 
Implementierung  verifiziert. 

22entnommen  aus  [Huckle06],  Seite  176 


(2.3.68) 


(2.3.69) 
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Integrationsschritts  kein  diskreter  Punkt  berechnet,  sondern  die  Taylorreihenentwick- 
lung der  gesuchten  Lösung  bestimmt23.  Die  Entwicklung  einer  Taylorreihe  hat  gegen- 
über den  klassischen  Methoden  den  entscheidenden  Vorteil,  dass  bei  jedem  Integrati- 
onsschritt eine  beliebige  Anzahl  von  Reihenkoeffizienten  berechnet  werden  kann.  Es 
ist  somit  ein  wertvolles  Werkzeug  zur  Verifikation  der  Standardverfahren,  da  hier  nur 
durch  einfaches  Erhöhen  des  Entwicklungsgrads  die  Genauigkeit  der  Lösung  gestei- 
gert werden  kann24. 


2.4.1    Rechnung  mit  Potenzreihen 

Das  Verfahren  der  Integration  von  Potenzreihen  basiert  auf  der  Verknüpfung  von  Rei- 
hen durch  mathematische  Operationen.  Nachfolgend  sollen  die  beiden  Funktionen  a(t) 
und  b(t)  als  Reihenentwicklung  um  den  Entwicklungspunkt  to  definiert  werden25: 

oo 

a(t)  =  y]{am)(t 

m=0 

oo 

m=0 

Werden  nun  die  beiden  Potenzreihen  a(t)  und  b(t)  mit  einer  arithmetischen  Operation 
verknüpft,  so  entsteht  eine  neue  Potenzreihe  c(t).  Dies  kann  wie  folgt  ausgedrückt 
werden: 

c(t)  =  a{t)ob(t),        og  (+,-,*, /,^—,exp,...)  (2.4.71) 
wobei  die  Koeffizienten  (cm)  durch  nachfolgend  beschriebene,  meist  rekursive  Bezie- 
ht) b(t) 


t0)m, 
to)m, 


(am) 
(bm)  ■ 


1  dma 
m\  dt™ '*=*° 


1  dmb, 
'm\~dlFl 


(2.4.70) 


|*=*o 


Abbildung  2.10:  Verknüpfung  von  Potenzreihen 


hungen,  angegeben  werden  können.  Zur  besseren  Vorstellung  sei  die  Verknüpfungs- 
vorschrift in  Abb.  2.10  illustriert.  Die  rekursiven  Beziehungen  zur  Verknüpfung  von 
Potenzreihenkoeffizienten  sind  ebenfalls  in  [Wanner68]  ( ab  Seite  10 )  und  in  [Schneider92] 
(  auf  Seite  396  und  397)  aufgelistet. 


23  siehe  dazu  [Montenbruck91] 

Dies  gilt  nur  innerhalb  des  Kc 
25Hierbei  wurde  die  Notation  aus  [MontenbruckSl]  (ab  Seite  7)  verwendet. 


24 Dies  gilt  nur  innerhalb  des  Konvergenzradius  der  jeweiligen  Reihe 
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2.4.2    Rekursionsformeln  zur  Verknüpfung  von  Potenzreihen 

Alle  Koeffizienten  (c)  einer  Taylorreihe  m-ter  Ordnung  können  wie  folgt  geschrie- 
ben werden: 


(c)m  =  (co)-(Cm) 


(2.4.72) 


Dabei  ist  beispielsweise  (co)  der  erste  Koeffizient  und  (cm)  der  letzte  Koeffizient  der 
Reihe.  In  Abbildung  2.1 1  sind  die  Potenzreihenkoeffizienten  illustriert. 


<ca> 

<c,  > 

<c3  > 

<c3> 

<c,> 

<cs> 

<c6> 

<c,> 

<c8> 

<cs> 

<cm> 

Abbildung  2.11:  Illustration  der  Potenzreihenkoeffizienten 


2.4.2.1  Addition  und  Subtraktion 

Potenzreihenkoeffizienten  können  analog  zu  Spaltenvektoren  gliedweise  addiert  und 
subtrahiert  werden  und  es  gilt  folgende  Verknüpfungsvorschrift: 

(cm)  =  (am)  ±  (bm)  (2.4.73) 

2.4.2.2  Multiplikation 

Die  Multiplikation,  auch  als  Cauchy-Faltung  bekannt,  ist  wie  folgt  definiert: 

m 

(cm)  =^2{ai){bm-i)  (2.4.74) 

i=0 

2.4.2.3  Division 

Die  Division  c(t)  =  |®  kann  aus  der  Multiplikation  hergeleitet  werden  und  ergibt: 

<c™>  =  TTT  |W  "  I]  <ci>  (fcm-i>  )  (2-4-75) 

Hierbei  gibt  es  einige  Unterschiede  zu  den  Grundrechenarten: 

•  Bei  der  Division  zweier  Potenzreihen  besteht  eine  Abhängigkeit  der  (cm)  -Terme. 
Diese  können  nur  in  aufsteigender  Reihenfolge  (Index  0...m  —  1)  berechnet  wer- 
den. Die  anderen  Grundrechenarten  besitzen  diese  Abhängigkeit  nicht  und  kön- 
nen prinzipiell  auch  parallel  berechnet  werden. 

•  Der  Rechenaufwand  zur  Berechnung  eines  Potenzreihenkoeffizienten  im  Falle 
der  Grundrechenarten  Addition  und  Subtraktion  unterscheidet  sich  nicht  von  der 
herkömmlichen  Rechnungen.  Im  Gegensatz  dazu  wächst  bei  der  Multiplikation 
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bzw.  Division  der  Rechenaufwand  etwa  proportional  zur  Ordnung26.  Der  Mehr- 
aufwand bei  der  Verknüpfung  zweier  Potenzreihen  der  Ordnung  m  steigt  für 
Additions  -  u.  Subtraktionsoperationen  linear.  Bei  Multiplikation  und  Division 
wächst  der  Aufwand  quadratisch  mit  der  Ordnung  der  Reihenentwicklung. 

2.4.2.4  Potenzbildung 

Die  Potenzbildung  kann  mit  Hilfe  der  Formel  zur  Multiplikation  (Cauchy-Faltung) 
hergeleitet  werden: 

c(t)  =  a{t)d,        d  G  N  A  d  >  0  (2.4.76) 

Durch  sukzessives  hintereinander  Anwenden  der  Vorschrift  zur  Multiplikation  ergibt 
sich  folgender  Ausdruck: 

1    1    (rn~l  \ 
(cm)  =  —-, — r    yZ(d(m  i){ci){am-i)    ,    m  G  N+  A  m,  (a0)  /  0 

m{a0)  \  f^0  J 

(co)  =  (a0)d 

(2.4.77) 

2.4.2.5  Berechnung  der  Quadratwurzel 

Die  Quadratwurzel  einer  Potenzreihe  c(t)  =  \J a(t)  kann  durch  folgende  Vorschrift 
bestimmt  werden: 

(cm)  =  ^  |W  -g^Xm  -  i>),  (ao)^0 

(co)  =  v^ööy 

2.4.2.6  Differentiation 

Die  erste  Ableitung  der  Potenzreihe  a'(t)  =  kann  nach  [Montenbruck91]  wie 
folgt  hergeleitet  werden: 


m=0 

oo 


d  ^2(am)(t-t0)m  (2.4.79) 


dt 

oo 
m=0 

Danach  gilt  folgende  Beziehung  für  jeden  Potenzreihenkoeffizienten: 

{a'i)  =  (i  +  l){ai+1)  (2.4.80) 


26 definiert  in  [Montenbruck91] 
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Diese  Eigenschaft  der  Potenzreihen  erlaubt  ein  einfaches  Differenzieren  einer  gesam- 
ten Potenzreihe,  ohne  großen  Rechenaufwand.  Dabei  ist  dennoch  Vorsicht  geboten, 
da  in  der  Praxis  die  Ordnung  m  endlich  ist  und  sich  durch  jede  Differentiation  die 
Ordnung  der  resultierenden  Reihe  um  eine  Ordnung  vermindert.  Dieser  Schwund  an 
Potenzreihenkoeffizienten  muss  bei  der  Implementierung  berücksichtigt  werden. 


2.4.2.7  Integration 

Analog  zur  Differentiation  kann  die  Integration  eines  Potenzreihenkoeffizienten  wie 
folgt  definiert  werden: 


/ 


<«i>  =  M>  i£N+ 

^  (2.4.81) 

(ao)  =  (-ao) 


2.4.2.8    Trigonometrische  Funktionen 

Zur  Berechnung  des  Sinus  bzw.  Cosinus  einer  Potenzreihe  b(t)  =  sin(a(t))  bzw. 
c(t)  =  cos(a(t))  kann  dies  durch  folgendes  Formelpaar  ausgedrückt  werden27: 


(sin(a(t))m)  =     —  y~"  (m  -  i)  (am_j)  (cos(a(t)i) 

l~°  (2.4.82) 

^  m—l 

{cos(a(t))m}  =  ^(m-  i)(am-i)(sin(a(t)i) 


m 

Hierfür  werden  folgende  Startbedingungen  benötigt: 

(sin(a(t)0))  =  sin((a(t)0))  ^ 
(cos(a(t)o))  =  cos((a(t)o)) 

Ferner  sind  in  [Wanner68]  (ab  Seite  31)  für  die  trigonometrischen  Funktionen  tan, 
atan,  asin  und  acos  die  rekursiven  Beziehungen  angegeben. 


2.4.2.9    Die  Exponentialfunktion 

Die  Exponentialfunktion  c(t)  =  exp(a(t))  kann  wie  folgt  auf  Potenzreihenkoeffizien- 
ten  angewandt  werden: 

j  m—l 

(c^)  =  -l](m-i)(ci)(am_1)  (24^ 
(c0)  =  exp((a0)) 


27Siehe  mehr  dazu  in  [Schneider93] 
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2.4.2.10  Logarithmus 

Der  Logarithmus  einer  Potenzreihe  c(t)  =  log{a(t))  kann  mit  folgendem  formelmä- 
ßigen Zusammenhang  ausgedrückt  werden: 


(co)  =  log((a0}) 

Bei  der  Berechnung  ist  wieder  die  Abhängigkeit  der  einzelnen  Potenzreihenkoeffizien- 
ten  der  Berechnungsvorschrift  besonders  hervorzuheben.  Hier  ist  analog  zur  Division 
und  der  Exponentialfunktion  keine  parallele  Berechnung  der  Koeffizienten  möglich, 
da  die  jeweils  vorangegangenen  Koeffizienten  zur  Berechnung  des  Koeffizienten  der 
nächsthöheren  Ordnung  benötigt  werden. 

Die  nachfolgend  angegebenen  rekursiven  Beziehungen  stellen  Erweiterungen  zu  den 
bereits  bekannten  Grundfunktionen  dar.  Sie  wurden  zur  Steigerung  der  Programmef- 
fizienz bei  der  programmiertechnischen  Umsetzung  von  Potenzreihenverknüpfungen 
ausgearbeitet. 

2.4.2.11    Fused  multiplication  and  addition  (fma) 

Diese  Befehlserweiterung  wird  von  einigen  Prozessorherstellern  angeboten,  um  drei 
Gleitkommazahlen  (a  +  b)  *  c  mit  nur  einem  Befehlsaufruf  miteinander  verknüpfen 
zu  können.  Dabei  wird  im  Falle  von  Gleitkommazahlen  i.d.R.  nur  ein  Prozessortakt- 
zyklus für  die  Berechnung  benötigt,  wohingegen  ohne  den  Aufruf  der  speziellen  fma- 
Funktion  dafür  nicht  garantiert  wird.  Diese  Namensbezeichnung  wurde  aufgegriffen 
und  auf  die  Verknüpfung  von  Potenzreihen  angewendet,  um  sowohl  unnötige  Funk- 
tionsaufrufe als  auch  unnötiges  Kopieren  von  Potenzreihenkoeffizienten  einzusparen. 
Somit  kann  die  fma- Verknüpfung  von  d(t)  =  a(t)  *  b(t)  +  c(t)  wie  folgt  beschrieben 
werden: 


Hier  wird  analog  zu  den  anderen  Verknüpfungsvorschriften  vorausgesetzt,  dass  die 
Potenzreihen  dieselbe  Ordnung  m  besitzen.  Analog  zur  fma- Verknüpfung,  kann  eine 
fms:  fused  muitipiica-  fms-Verknüpfung  (Subtraktion)  definiert  werden  durch  : 

tion  and  subtraction 


(2.4.85) 


rn 


(2.4.86) 


m 


(2.4.87) 


2.4.2.12    Häufig  verwendete  Potenzen  a(t)2,  a(t)3  und  a(t)4 


Für  häufig  verwendete  konstante  Potenzen  kann  eine  vereinfachte  Vorschrift  erstellt 
werden.  Das  Quadrieren  a(t)2  einer  Potenzreihe  ist  eine  Vereinfachung  der  Potenzbil- 
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dung: 

(m-\ 

m  (a0) 
(co>  =  (a0) 


(cm)  =  —-f—r  (  y^(2(m  -  i)  -  i)(ci)(am-i)  )  ,     me  N+  Am,  (a0)  /  0 


,  i=0 


(2.4.88) 


Hinsichtlich  einer  effizienten  Abarbeitungsgeschwindigkeit  empfiehlt  sich  die  Imple- 
mentierung dieser  Vorschriften  für  die  jeweiligen  Fälle.  Dadurch  können  unnötige 
Funktionsaufrufe  vermieden  und  folglich  kostbare  Rechenzeit  eingespart  werden. 

2.4.2.13    Die  Z2-Norm 

Besonders  bei  der  Lösung  von  Bewegungsproblemen,  wie  beispielsweise  dem  Kepler- 
problem,  ist  es  üblich,  den  Ort  x,y,z  und  die  Geschwindigkeit  x,  y,  z  in  dreidimen- 
sionaler Vektorschreibweise  anzugeben.  Hierbei  wird  häufig  die  L2-Norm  |r|  benötigt, 
welche  mathematisch  wie  folgt  definiert  ist: 

\r\  =  y/x2  +  y2  +  z2  (2.4.89) 

In  Potenzreihendarstellung  r(t)  =  y/x2(t)  +  y2(t)  +  z2(t)  kann  folgende  Vorschrift 
zur  Berechnung  der  jeweiligen  Koeffizienten  angegeben  werden.  Diese  muss  in  zwei 
Schritten  erfolgen,  da  sowohl  die  Potenzbildung  als  auch  die  Quadratwurzel  die  bereits 
erwähnte  nicht  parallelisierbare  Eigenschaft  besitzen. 
Schritt  1:  r(t)  =  {x2(t)  +  y2(t)  +  z2{t)) 

1      (m~X  \ 
(r™>  =  (  S(2(m-i)-i)(ri)(a:m-i))  1 

+  ^)  1  E(2(™-*)-*)<n><ym-*>)  J  (2.4.90) 


,  i=0 
/  m— 1 


+  (  j](2(m-i)-i)(ri)(2ro_i)) 


i=0 

2   ,    /„.  \2   ,    /  \2 


(ro)  =  (x0)2  +  (yor  +  <*ö> 

Schritt  2:  c(t)  =  y/r{£) 

m—l 


<Cm>  =  2^y^(rm>-g<r<><m-<>J,     <r0>  /  0  ^  ^ 

(co)  =  v/(n>) 


2.4.3    Potenzreihenintegration  in  der  Praxis 

Nachdem  die  nötigen  Formeln  zur  Verknüpfung  von  Potenzreihen  bekannt  sind,  kann 
das  Integrationsverfahren  von  Potenzreihen  beschrieben  werden.  Hierbei  wird  ana- 
log zu  den  anderen  Integrationsverfahren  eine  gewöhnliche  Differentialgleichung  ge- 
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löst.  Die  formelmäßige  Darstellung  der  Potenzreihe  wird  hierfür  als  Verknüpfungs- 
vorschrift verwendet,  wobei  jede  Verknüpfung  einer  der  hier  definierten  Formeln  ent- 
spricht. Somit  kann  für  jeden  Integrationsschritt  eine  Potenzreihe  m-ter  Ordnung  ent- 
wickelt und  im  Anschluss  zum  Zeitpunkt  t\  ausgewertet  werden.  Um  das  Verfahren 
zu  veranschaulichen  wird  beispielhaft  anhand  der  ungedämpften  Dufflngschen  Oszil- 
latorgleichung die  Entwicklung  einer  Potenzreihe  der  Ordnung  m  =  3  schrittweise 
durchgeführt: 

Beispiel  2.9  für  „Der  ungedämpfte  Duffing  Oszillator" 

Die  Entwicklung  der  Potenzreihe  erfolgt  in  vier  Schritten.  Die  Abarbeitungsreihenfolge  wird 
durch  die  Rechengesetze  der  Grundrechenarten  vorgegeben  und  ist  in  Abb.  2.12  dargestellt. 


d2u(t)         2  -  -(3) 

 ———(JÖM{t)  —  ÖM[t) 

dt  T  AT 

(1)  (2) 
(4) 

Abbildung  2.12:  Formale  Darstellung  der  Duffmg-Oszillatorgleichung 


Das  Zwischenergebnis  nach  der  (1 ).  Verknüpfung  r\  und  r\  hat  folgende  Gestalt: 

1 


du 
~dt 


h  —  -uP'uh2 


r\  =  —uhiü"  + 


du  1  du 
~dt  ~  2  ~dt 


(2.4.92) 


u2  2 


Hierbei  ist  zu  beachten,  dass  bei  jeder  Verknüpfung  zwei  Reihen  entwickelt  werden.  Eine  Reihe 
beschreibt  den  Ort  (r±)  und  die  andere  die  Geschwindigkeit  (r\).  Die  Zwischenergebnisse  T2 
und  f%  des  zweiten  Teilschritts  (2)  haben  folgende  Darstellung: 


du,       1  r,2 

r?  =  u  H  h  uoh 

dt  2 

1  du  2 
ro  =  —uoh  oh  4 

2  dt 


du 

~dt 


(2.4.93) 


Beim  nächsten  Teilschritt  (3)  erfolgt  eine  Potenzbildung  der  Reihenkoeffizienten: 


du     1  2  q 
r3=u  +  h--2huö 

r3  =  -hu*6-3-h*u2ft5- 


du 


(2.4.94) 


Im  letzten  und  (4). Schritt  werden  die  Teilergebnisse  r2,r%  und  r2,T's  aufsummiert.  Dies  ergibt: 
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2.4.4    Die  Taylorreihenmethode 

Die  Taylorreihenmethode  kann  angewendet  werden,  falls  genügend  Ableitungsterme 

,  d  faf*  i  d dtf1  einer  Funktion  y(t)  vorhanden  sind.  Eine  stetig  differenzierbare 
Funktion  ist  dabei  vorausgesetzt.  Ist  dies  gegeben,  können  beispielsweise  auf  analy- 
tischem Weg  höhere  Ableitungsterme  bestimmt  werden  und  der  Funktionswert  zum 
Zeitpunkt  t  +  h  mit  Hilfe  einer  Taylorreihe  bestimmt  werden.  Bei  der  Auswertung 
dieser  muss  jedoch  auf  den  Konvergenzradius28  r  geachtet  werden.  Dieser  beschränkt 
die  Länge  des  Zeitschritts  h  und  es  gilt  somit  h  <  r.  Ferner  ist  der  Restgliedfehler  zu 
beachten,  d.h.  wird  die  Reihenentwicklung  bei  einer  bestimmten  Ordnung  n  abgebro- 
chen, dann  liegt  der  Restgliedfehler  in  der  Größenordnung  des  n+  1-ten  Reihenglieds. 
Das  Auswerten  der  jeweiligen  Reihe  kann,  ähnlich  der  Integration,  in  Schritten  h  un- 
terschiedlicher Länge  durchgeführt  werden  und  stellt  somit  eine  weitere  Methode  zur 
Lösung  von  Differentialgleichungen  dar.  Hierfür  wurden  für  das  Keplerproblem  und 
das  Hauptproblem  der  Himmelsmechanik  die  Taylorreihen-Koeffizienten  formelmäßig 
erarbeitet.  Diese  sind  im  Anhang  C  und  D  aufgelistet. 

Beispiel  2.10  für  „Ein  unangenehmes  Beispiel" 

Mit  diesem  Beispiel  sollen  die  Grenzen  einer  Taylorreihenentwicklung  aufgezeigt  werden.  Dazu 
wird  ein  populäres  Beispiel  aus  der  einschlägigen  Fachliteratur  herangezogen  (  [Collatz66], 
Seite  49  ): 

d^)  =  1Qdyß  +  (2  4  %) 

dxz  dx 

mit  den  Anfangswerten  y(x)  =  1,  dy^  =  —1  an  der  Stelle  x  =  0.  Hieraus  soll  eine  Taylor- 
reihe entwickelt  werden.  Anschließend  soll  die  Lösung  an  der  Stelle  x  =  1  berechnet  werden. 
Aus  der  angegebenen  Differentialgleichung  können  nun  höhere  Ableitungsterme  gebildet  wer- 
den, um  daraus  eine  Taylorreihe  aufzubauen.  Die  Ableitungsterme  können  durch  folgendes 
Bildungsgesetz  ausgedrückt  werden: 

d4y(x)     in  /  d3         \  f  d2     ,  . 


dny(x)  (  d"-1      .  ,\          /  dn-2     ,  \ 


dxn 


Wobei  n  der  Platzhalter  für  den  jeweiligen  Grad  der  Ableitung  ist.  Daraus  kann  durch  Einset- 
zen der  Ableitungsterme  folgende  Taylorreihe  n-ter  Ordnung  aufgebaut  werden: 

dy(x)  x      d2y(x)  x2  dny(x)  xn 

V(X)       dx    1!       dx2    2!     '•'       dxn  n\ 
Einsetzen  der  Ableitungsterme  ergibt 

,  .      dy(x)  x       n  (  d2      .  ,\     ,    /  d     .  X  x2  n  (  d^1      .  \  /  dn-2     ,  .\ 

+  n  +  10  (—2  y  (x) )  +  11  (-  y  (*))  -  +  ...  +  10  ^  y  (*)  j  +  11  (—2  y  (*)  j 

Für  dfen  Fall  x  =  1  t/nc/  Mnfer  Ausnutzung  der  bekannten  Anfangswerte  für  y{x)  =  1  Mnaf 
=  —  1  können  die  ersten  acht  Taylorkoeffizienten  in  rücksubstituierter  Form  dargestellt 
werden: 


IV. 


28siehe  mehr  dazu  [Bronstein08]  auf  Seite  463 
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Ableitung 

Koeffizient 

y{x) 

1 

dy(x) 
dx 

-1 

d'y(x) 
dx2 

wdy(x)  +lly(x) 

d:iy{x) 
dx3 

lndy{x)  +n0y{x) 

diy{x) 
dx4 

12431  dy}x)  +  12210y(x) 

d:'y(x) 
dx5 

154541971        +  151782510y(.T) 

d6y{x) 
dx6 

23883220952347351  dy}x)  +  23456768258727210y(x) 

d'y(x) 
dx7 

570408243058643531122685215444411 dy}x)  +  560223179151189990635941075120710y(x) 

Anhand  der  überaus  großen  Zahlen  kann  bereits  ein  Trend  erahnt  werden.  Beispielsweise  be- 
sitzt der  elfte  Ableitungsterm  Faktoren  mit  einer  Länge  von  525  Dezimalstellen29 .  Dies  liegt 
weit  jenseits  der  herkömmlich  verfügbaren  Genauigkeit  einer  Standardbibliothek  zur  nume- 
rischen Verarbeitung  von  Zahlen.  Dies  zeigt  somit  eine  große  Schwäche  der  Taylorreihenme- 
thode. Werden  die  Faktoren  der  jeweils  verwendeten  Ableitungsterme  zu  groß,  so  können  sie 
nicht  auf  Standarddatentypen  abgebildet  werden.  Wird  dies  dennoch  versucht,  wird  die  Zahl 
bei  der  Initialisierung  auf  die  verfügbare  dezimale  Genauigkeit  gerundet  und  ist  somit  mit  ei- 
nem Fehler  behaftet.  Dies  führt  zu  einem  verfälschten  Ergebnis,  welches  abhängig  von  der 
Größenordnung  des  Fehlers  das  Ergebnis  mehr  oder  weniger  unbrauchbar  macht.  In  Tabelle 
2.5  ist  das  Ergebnis  an  der  Stelle  x  =  1  angegeben.  Dabei  stellt  die  analytisch  berechnete 
Methode  das  korrekte  Ergebnis  dar.  Die  Formel  zu  Berechnung  ist  auch  in  [Collatz66]  (Seite 
49)  angegeben  und  soll  hier  aus  Gründen  der  Vollständigkeit  aufgeführt  werden: 

e~x  (2.4.97) 


Analytisch 

Taylorreihenmethode 

0.367879 

2.7757e  +  15 

Tabelle  2.5:  Ergebnis  der  analytischen  Lösung  und  der  Taylorreihenmethode  an  der 
Stelle  x  =  1 


Wie  aus  Tabelle  2.5  abzulesen  ist,  haben  die  beiden  Ergebnisse  nichts  mehr  miteinander  zu 
tun.  Aus  diesem  Grund  ist  bei  der  Taylorreihenmethode  im  Vorfeld  genau  zu  prüfen,  ob  die 
gewünschte  Funktion  zur  Lösung  mit  der  Taylorreihenmethode  geeignet  ist. 

2.5    Vergrößerung  der  Integrationsschrittweite 

Soll  über  einen  langen  Zeitraum  integriert  werden,  sind  lange  Integrationsschrittwei- 
ten wünschenswert.  Wird  mit  einem  Standard  verfahren  integriert,  beispielsweise  ei- 
nem Runge-Kutta- Verfahren  fester  Ordnung,  so  verschlechtert  sich  das  Ergebnis  mit 
zunehmender  Schrittweitenlänge  h.  Wird  andererseits  ein  Potenzreihenintegrations- 
verfahren  verwendet,  so  kann  die  Ordnung  der  entwickelten  Reihe  dynamisch  gewählt 

29Der  25. Ableitungsterm  besitzt  sogar  über  34  Millionen  Dezimalstellen. 
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werden.  Diese  wiederum  ist  i.d.R.  durch  den  Konvergenzradius  begrenzt  und  ver- 
hindert somit  ebenfalls  große  Schrittweitenlängen.  In  diesem  Abschnitt  soll  eine  Mög- 
lichkeit aufgezeigt  werden,  wie  mit  Hilfe  symbolischer  Rechnung  -  angewendet  auf 
die  Potenzreihengesetze  -  eine  Vergrößerung  der  herkömmlich  möglichen  Integrati- 
onsschrittweiten erreicht  werden  kann.  Als  Ausgangspunkt  hierfür  kann  das  Verfahren 
der  Potenzreihenintegration  verwendet  werden.  Wird  eine  gewöhnliche  Differential- 
gleichung mit  diesem  Verfahren  gelöst,  dann  wird  für  jeden  Integrationsschritt  eine 
Potenzreihe  der  Ordnung  m  entwickelt.  Die  so  entwickelte  Reihe  ist  somit  auf  das  zu 
lösende  Problem  zugeschnitten  und  kann  innerhalb  des  Konvergenzkreises  ausgewer- 
tet werden.  Nach  dem  Auswerten  der  Reihe  stehen  wieder  Anfangswerte  zur  Verfü- 
gung, aus  denen  unter  Verwendung  der  Differentialgleichung  und  den  Gesetzen  der 
Potenzreihenentwicklung  erneut  eine  Reihe  entwickelt  werden  kann. 

Beispiel  2.11  für  „Entwicklung  einer  Reihe  zur  Lösung  der  Duffingschen  Oszillatorglei- 
chung 3.0rdnung" 

Im  ersten  Schritt  ist  es  erforderlich,  anhand  vorgegebener  Startwerte  u  und  ü  =  ^  eine  Reihe 
3.  Ordnung  des  Ortes  (u(t  +  h))  zu  entwickeln.  Hier  ist  t  der  Startzeitpunkt,  h  entspricht  der 
Integrationsschrittweite  und  lj,5  sind  Integrationskonstanten.  Ferner  ist  eine  zweite  Reihe  für 
die  erste  Ableitung  nach  der  Zeit  (ü(t  +  h)j  aufzubauen.  Beide  Reihen  haben  folgende  Gestalt: 


u(t  +  h)  =u  +         -  -h2uj2u  -  -eh2u3 

ldu  3     du  (2'5-98) 

ü(t  +  h)  =  du  —  h2w2  u2  —  5h2  —  uhuo2  —  u3öh 

v        ;  2  dt  2  dt 


Diese  Reihen  können  nun  im  Intervall  \—h,  h~\  ausgewertet  werden.  Wird  h  =  0  gesetzt,  dann 
erhält  man  den  Entwicklungspunkt  der  Reihe.  Dieser  fällt  mit  dem  jeweiligen  Anfangs  werten 
u  und  ü  zusammen.  Nochmaliges  Anwenden  derselben  Methode  auf  die  entwickelte  Reihen 
liefert  folgende  Reihendarstellung: 

u(t  +  2h)  -  ^3Ä  W  +  lu4d"ö2h5  ~  -  lA3Sh5  +  \uhW  -  lu3ShW 

y         '     4    ydt'  2     dt  8  2ydt'  4  8 

-  l^fSh4  +  ^-u3Sh8u;6  -  \u552h6ui2  +u+  lu^öhW  -  2u3Sh2 
2     dt  16  4  2  dt 

+  2^h  -  2uh2u2  -  3ued^53h7  +  3uA2Sh6co2  -  Zu2<^5h3  +  u3ShW 
dt  8     dt  4  ydt'  dt 

+  JL„W  +  -uWü/  +  -u753hW  -  ^hW  -  3<A2/>v 
16  16  16  dt  4  dt 

8     dt  4 

(2.5.99) 


'  siehe  mehr  dazu  unter  [Rade97] 
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u(t  +  2h)  =  ^<Ä2/A,4  +  f  u4^V/i4  -  \A35h4  +  3uW  -  L5A2S3h7 

-LU        CLL  i-  (JLv  £     CLL  i-  (Jiv 

-  lu5S2hW  +  \u954h7  -  ?uW  +  lu3Sh7u6  -  2u35h  +  9u3Ä  W 

-  -u35hhLüA  +  4u3Sh3oj2  +  ^ue^ö3hW  -  ^ued^ö3h6  -  5uÄWw4 
4  16     dt  8      dt  4  ydt' 

+  9u2d^6hW  -  2uhu2  +  ^  +  ~h4u4  -  3u3A2ö2h7u2  +  lu5S2h7u4 
dt  dt      4  dt  ydt'  2 

+  lu783h7u2  +  ^-usd^64h8  -  6u2^Sh2  -  6uA25h3  +  VÄW 
2  16     dt  dt  Kdt'  4  ydt' 

_  2^äV  +  uh3iü4  +  6uA2öhW  -  ^u^öhW  +  h^föhW 
dt  KdtJ  8      dt  Vdt> 

 -u  —  Szhbu}2  +  —  uz  —  öh8ojb 

4      dt  16  dt 

t/m  die  etwas  umfangreichen  Ausdrücke  zu  verkleinern,  werden  die  Integrationskonstanten 

CO  =  1  t/nd  ^  =  ygg  8esetzt-  ^es  ergibt: 

u(t  +  2h)  =  -2uh2  +  -^—u5h8  +  2^h  -  —A3h5  +  u7h8  +  u  -  —u3h6 

y         '  160000  dt       200 v  dt 1         16000000  800 

3    9du  ,       1     ,  .  3        ^  du  -     du  ,       3     . du . 2 ,  fi        3      r ,  fi 

 u2 —  h3  H  u3/i4  ub —  h7  tr  H  u( —  Yhb  ubhb 

100     dt         100  8000000     dt         dt        400  1  dt ;  40000 

200     dt        50  200  y  dt'         40000  1600000000 

_  ^u2  —  h7  +  —  u3h8  +  -uh4  u7h6  +  -^—u4  —  h5  -  -^—u4  —  h7 

800     dt         1600  4  8000000  20000     dt        40000  dt 


40000    V  dt ; 


(2.5.100) 


.  /        7 1         9      9/dw.o,fi       3,du.o,fi  1         n  7       ,o       3     o  du ,  o      1  .  du , 

U(U  +  2/l)  -  4ÖÖÖÖM Ä  >8*6  +  4ÖÖ<  dt >  h  +  2WMmöUk  +  Uh  +  16ÖÖ"  V  -  4Ö(  dt ' 

+  JLUW  -  2^h2  +  -^—u5h3  -  -J—u5A2h7  -  ^uA2h3  -  ^-u2^h2 
200  dt         10000  4000000    K  dt'         50  v  dt '         50  dt 

9     o ,  r         39       «  du ,  fi     „  ,         3      ddu  „     1  du ,  d       9    9 du ,  d 
"  4ÖÖM 3fcB  '  SIMM)"  dt  ^  -  2M/l  +  32ÖÖÖ"  dt  fc8  +  4  ÄÄ  +  IÖÖU  dt  h 

lo,o        3      c,7     du       3     , du. ,,7  9  «du,o      27    9 du,  fi 

+  25"  Ä  +  2(M)ÖU  Ä  +  dt  -  4ÖÖW( dt }  *  +  1600000000"  d^'  "  8Öö"  ÄÄ 

3  9        r,r  39       4  du  ,  4  3  7,7  9  q/du.9,^ 

+  50^ dt )  ft  -  2ÖÖÖÖ"  "  +  4ÖÖÖÖ"  dt h  +  2mmu  h  +  mööu  {Tt)  h 

1  9        7lr        3      c.,du,2,7       33     4dit,fi  21  fidu,s 

50  4000000  10000    v  dt ;         40000     dt         16000000  dt 

Durch  Festlegen  der  Anfangswerte  auf  konkrete  numerische  Werte  u  =  1  und      =  0  können 
die  Ausdrücke  weiter  vereinfacht  werden.  Einsetzen  der  Werte  ergibt: 

,                   101,9       1030301    ,8      30603  ,fi     10403, 4 
u(t  +  2/i  =  1  h2  -\  h8  he  H  h4 

y         '           50         1600000000        8000000        40000  f2  5  1fm 

•  /              10403,,     101,       1030301  ,7      91809  ,  «=  1  J 

ü(t  +  2/7,  =  /i3  h  H  /i7  h5 

v         ;     10000         50        200000000  4000000 

An  dieser  Stelle  hängen  die  beiden  Ausrücke  für  Ort  und  Geschwindigkeit  nur  noch  von  der 
Schrittweite  h  ab.  Wird  nun  eine  bestimmte  Schrittweite  gewählt,  z.B.:  h  =  jgg  ergibt  dies  den 


2.5  VERGRÖSSERUNG  DER  INTEGRATIONSSCHRITTWEITE 


41 


Abszissenwert  an  der  Stelle  t  +  ^  der  Duffingschen  Oszillatorgleichung.  Für  den  Fall  h  = 
können  folgende  numerische  Werte  angegeben  werden: 


15996768041611938795030301 

U^t+     >~  16000000000000000000000000 

=  0.999798 

.,  403979194045903469699 
ü(t  +  2h)  =  - 


20000000000000000000000 
=  -0.002019895970229517348495 

Ein  Vergleich  mit  der  analytischen  Lösung  30. Ordnung11  ergibt  Folgendes: 


(2.5.102) 


Analytische  Lösung  (30.Ordnung) 

u(t  +  2h) 

0.999798006935221 7684987 

0.99979800 

Hierbei  stimmt  das  Ergebnis  mit  der  analytischen  Lösung  30.Ordnung  bis  zur  achten  Nach- 
kommastelle überein. 

Wie  dieses  Beispiel  demonstriert  hat,  ist  es  prinzipiell  möglich,  eine  bestimmte 
Anzahl  von  Zwischenschritten  zu  übergehen.  Sollen  mehrere  Schritte  überbrückt  wer- 
den, so  steigt  die  Anzahl  der  Terme  sehr  schnell  an,  was  sich  nachteilig  auf  die  Ab- 
arbeitungsgeschwindigkeit in  der  Implementierung  auswirkt.  Ein  wesentlicher  Unter- 
schied zu  den  Standardverfahren  ist,  dass  die  hierfür  erarbeiteten  Ausdrücke  exakt  auf 
die  Problemstellung  zugeschnitten  sind  und  nicht  mehr  allgemeingültig  für  eine  be- 
stimmte Klasse  gewöhnlicher  Differentialgleichung  geeignet  sind.  Basierend  auf  die- 
ser Methode  ist  es  möglich,  ein  Integrationsverfahren  fester  Ordnung  zu  entwerfen, 
das  jeden  n.ten  Abszissenwert  (n  <E  N,n  >  1)  liefert. 

Beispiel  2.12  für  „Konstruktion  eines  analytischen  Duffing-Integrators  3.0rdnung" 

Hier  soll  beispielhaft  ein  Integrationsverfahren  zur  Lösung  der  ungedämpften  Duffingschen 
Oszillatorgleichung  erstellt  werden.  Darüber  hinaus  soll  das  hier  konstruierte  Verfahren  nur 
bei  jedem  zweiten  Integrationsschritt  einen  Abszissenwert  erzeugen.  Ferner  ist  in  Abb.  2.13 
die  Arbeitsweise  der  hier  verwendeten  Methode  zur  Konstruktion  einer  spezialisierten  Lösung 
illustriert.  Hierfür  wird  auf  das  bereits  erarbeitete  Ergebnis  des  vorangegangenen  Beispiels 
zurückgegriffen.  Sollen  mehrere  Schritte  nacheinander  mit  unterschiedlicher  Schrittweitenlän- 
ge berechnet  werden,  so  müssen  die  Reihen  von  u(t),  ^  und  von  h  abhängig  sein.  Dadurch 


3 'Diese  wurde  in  [Maill]  erarbeitet.  Im  Rahmen  dieser  Arbeit  wurde  eine  C++- Version  der  Lösung 
30. Ordnung  implementiert. 
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Q  übersprungene  Punkte 
£  ausgewertete  Punkte 
  FunktionsverlauT 


Abbildung  2.13:  Veranschaulichung  des  analytischen  Duffing-Integrators  3. Ordnung 


ergibt  sich  folgende  formelmäßige  Darstellung  in  Abhängigkeit  von  der  Schrittweite  h: 


u(t  +  2h) 


3  , ß -  du . o  3 

 h°( —  Yu  

400    v  dt '  8000000 


6„,7 


h°u 


3  ,  r  dU  n 
 ^°  <..z 

200     dt ' 


h7 

) 

3 


du 


„,  dU  1    ,  n  o 

2ft  h2u3  - - 

dt     50  40000  dt 


1  .sin,,  3 

 h5(  —  Y  H  

200    v  dt 7  160000 

8„,7 


4„,5 


40000 


/i4u 


1 


,  , du  1- 

hA  h  -/i  u  + 

dt     4  1600000000 

— 
1600 


8„,9 


/l8U 


16000000 


3 


,du 


40000 


8000000  dt 

/i6u5 


h6(~  )2u3 
40000    v  dt ' 


,5 


du 


— /i  ( — Yu-\  

200    vdr        20000  dt 

800  800  dt 


1 

100' 


4„,3 


-/l4U 


3  ,  o  du  n 
100  dt 


(2.5.103) 


„ , .         3    , 7  k        3    ,sd«  ,     du       9     .4  ,        3    , 7 , du . ,  ,         3  ,77 

w(<  +  2/l)  ^  2ÖööoäV  +  32ÖÖÖ*  V  +  Tt  +  iöö*  V  ~  iöööö*  <*>  "  +  2000000^ 

9    ,  R/dn.o  ,     ,o        1  ,A,du„  21      ,  adu  fi       33    ,  «du  4      3  ,9du  9 

+  40000^  (d^)V  +  *  >u  "  4Ö/l%)  +  16000000^  dt "  -  4ÖÖÖQ*  V  -  50  dt 
9    ,55         39     l6du  6     ll4 du      1,  ,         9      , 5  7      3  ,6,du.3 

"  20ÖÖÖ*  "  -  mmmh  dt u  +  4^  dt  +  25^  "  4(XM)oö/lV  +  Woh  ^ 

50    v  dt '        400    v  dt ;        10000  10000    v  dt ;         800  dt 

9        ,sdus      9,5,       3,s du,       39    , Adu  ,       , ,  du      3  , 5 . du . 9 

+  läöööööööö*  V  "  400^  u  +  moh  Ttu  +  4oooo/lV  ~2h  dt  +  50  dt 

 9  h7(  — )  V  -  -^u3  +  1  h7u9  +  —  h7u3 

4000000    ydt'         50  200000000  200 

Diese  Formeln  können  nun  zur  Konstruktion  eines  Integrationsverfahrens  verwendet  werden. 
Sie  liefern  durch  iteratives  Einsetzen  des  jeweils  vorangegangen  Ergebnisses  die  Abszissen- 
werte in  äquidistantem  Abstand  (2h).  Um  herauszufinden  welche  maximale  Schrittweite  h 
verwendet  werden  kann,  wurde  das  Ergebnis  mit  der  analytischen  Lösung  (30.Ordnung)  ver- 
glichen. Der  Vergleich  der  Lösung  3.  Ordnung  und  4. Ordnung  mit  der  analytischen  Lösung 
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ist  in  Abb.2.14  dargestellt.  Dabei  wurden  für  die  jeweiligen  Ordnungen  Lösungen  im  Inter- 
vall [0,  0.6]  errechnet  und  diese  mit  der  analytischen  Lösung  verglichen,  indem  der  absolute 
Fehler  der  beiden  Lösungen  bestimmt  wurde.  Besonders  auffällig  beim  Vergleich  der  Lösung 
3.  Ordnung  ist,  dass  der  Fehler  nach  ca.  dreiviertel  des  untersuchten  Intervalls  schon  bei  0.001 
liegt.  Der  Grund  für  den  schnellen  Anstieg  liegt  am  verhältnismäßig  kleinen  Entwicklungsgrad 
( 3. Ordnung)  der  hier  erarbeiteten  Lösung.  Um  dies  zu  bestätigen  wurde  eine  Lösungsformel  4. 
Ordnung  erarbeitet.  Der  Vergleich  dieser  Lösung  mit  der  analytischen  Lösung  zeigt,  dass  mit 
zunehmender  Ordnung  der  Anstieg  des  absoluten  Fehlers  abflacht.  Mit  Hilfe  dieser  Vergleiche 
kann  der  Anstieg  des  Fehlers  für  einen  Integrationsschritt  in  Abhängigkeit  der  verwendeten 
Schrittweite  und  Ordnung  abgeschätzt  werden.  Daraus  kann  in  Abhängigkeit  des  erlaubten 
Fehlerbudgets  eine  sinnvolle  Schrittweite  h  gewählt  werden.  Wird  nun  eine  bestimmte  Schritt- 


0,0035  p 

0.003  - 

0,0025  - 

fc         0,002  - 
Ii 

1 
o 

S       0,0015  - 
0,001  - 
0,0005  - 
0  L 

0  0,1  0,2  0,3  0,4  0,5  0.6 

Schrittweite  h 

Abbildung  2.14:  Vergleich  mit  analytischer  Lösung 


weite  gewählt,  so  kann  durch  mehrfaches  hintereinander  Ausführen  dieser  Formeln  die  gesuch- 
te Lösung  berechnet  werden. 

Um  das  hier  vorgestellte  Integrationsverfahren  komfortabler  zu  gestalten,  wäre  ei- 
ne automatische  Steuerung  der  Schrittweite  wünschenswert.  Eine  dynamische  Ände- 
rung der  Schrittweite  ist  in  fast  allen  Fällen  nötig,  um  den  resultierenden  Gesamtfehler 
( ohne  Berücksichtigung  von  Eingangs-  und  Rundungsfehler)  zu  überwachen.  Ansätze 
zur  Implementierung  einer  adaptiven  Schritt  Weitensteuerung,  basierend  auf  Potenzrei- 
henintegrationsverfahren,  ist  in  [Wanner68]  ab  Seite  128  zu  finden.  Dort  werden  ver- 
schiedene Ansätze  zur  Schrittweitensteuerung  diskutiert  und  es  wird  eine  Formel  zu 
Abschätzung  der  Schrittweite  in  Abhängigkeit  des  vorangegangen  Schritts  angegeben. 
Die  optimale  Schrittweitensteuerung  wird  ferner  in  [Morrison62]  diskutiert. 
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2.6    Bewertung  der  numerischen  Integrationsverfahren 

In  diesem  Abschnitt  sollen  die  verwendeten  numerischen  Integrationsverfahren  hin- 
sichtlich ihrer  Abarbeitungsgeschwindigkeit,  der  Anzahl  der  benötigten  Funktionsauf- 
rufe und  ihres  Fehlerhaushalts  anhand  einschlägiger  Beispiele  bewertet  werden.  Als 
anfängliches  Beispiel  soll  die  ungedämpfte  Dufnng-Oszillator-Gleichung  zur  Lösung 
mit  Hilfe  einer  Auswahl  numerische  Integrationsverfahren  gelöst  und  die  numerisch 
bestimmten  Lösungen  mit  der  analytischen  Lösung  30.Ordnung32  verglichen  werden. 
Im  Anschluss  wird  die  Lösung  einer  Keplerbahn  mit  verschiedenen  Integrationsver- 
fahren berechnet  und  die  Güte  der  Lösung  beurteilt. 


K  a  Itgü  risi  eru  n  g 

Lösungsverfahren 

Schrittweltens  tenenmg 

DG  Ordnung 

Ein  sehrt  tt- 

Mehrschriti- 

Potenzrelhe 

Symplektiseh 

1 

2 

v  erfahren 

verf ahren 

Shampine  Gomfon  (SG) 

i 

i 

i 

Burliseh  Stow  (BS) 

■ 

■ 

■ 

Gaus  »-Jackson  (GJ4) 

II 

■ 

Runge  Kutta  4. arder  (RK4) 

■ 

Runge  Kutta  LO.order  (RK10) 

a 

Dürmund-Prinet  (DOPRI) 

■ 

■ 

Leap-Frog  (LF) 

■ 

■ 

Symptectic  (SYMP) 
4.  - ,  6.  -and  Vorder 

■ 

a 

Power  series.  (POWSER) 

■ 

■ 

Abbildung  2.15:  Einordnung  der  implementierten  Lösungs verfahren  mit  deren  Eigen- 
schaften 


2.6.1  Fehlerbetrachtung 

Um  für  einen  bestimmten  Fall  beurteilen  zu  können,  welches  Integrationsverfahren 
das  jeweils  bessere  ist,  wird  hier  auf  die  bereits  definierten  Fehlernormen  (siehe  Ab- 
schnitt 2.1  auf  Seite  6)  zurückgegriffen.  Die  numerische  Lösung  von  DG  weist  jedoch 
eine  spezielle  Eigenschaft  hinsichtlich  ihres  Fehlerhaushalts  und  der  Entwicklung  des 
Gesamtfehlers  g  auf.  Wird  nur  der  Verfahrens-  und  Rundungsfehler  er(j  betrachtet, 
so  kann  deren  jeweiliger  Beitrag  zum  Gesamtfehler  in  Beziehung  zur  gewählten  Inte- 
grationsschrittweite h  gesetzt  werden.  Dieser  Zusammenhang  wird  in  Form  einer  Feh- 
lerkorrelation in  Abb.  2.16  qualitativ  dargestellt.  Aus  dieser  Fehlerbetrachtung  lässt 
sich  eine  optimale  Schrittweite  hopt  ableiten.  Diese  liegt  im  Schnittpunkt  zwischen 
der  Funktion  des  Rundungs  -  und  lokalen  Diskretisierungsfehlers.  Bei  Verfahren  mit 
adaptiver  Schritt  Weitensteuerung  wird  versucht,  stets  die  optimale  Schrittweite  zu  fin- 
den um  die  Fehlerbeiträge  möglichst  gering  zu  halten33.  Einige  der  Lösungs  verfahren 
besitzen  eine  feste  Konsistenzordnung,  wodurch  der  lokale  Diskretisierungsfehler  in 
Abhängigkeit  der  jeweils  gewählten  Schrittweite  genau  bestimmt  werden  kann.  Da- 
bei ist  die  Konsistenzordnung  auf  den  Vergleich  der  numerisch  bestimmten  Lösung 

32 siehe  mehr  dazu  unter  [Mail  1] 
"siehe  dazu  [Speith07] 
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Abbildung  2.16:  Fehlerkorrelation  von  Rundungs  -  und  Diskretisierungsfehler  in  Ab- 
hängigkeit der  Integrationsschrittweite 

Y(t  +  h)  und  der  exakten  Lösung  y(t  +  h)  zum  Zeitpunkt  t  +  h  zurückzuführen.  Bei- 
spielsweise ist  einem  Einschrittverfahren  die  Konsistenzordnung  p  zuzuordnen,  falls 
gilt: 

Y(t  +  h)  -  y(t  +  h)  <  0(hp)  (2.6.104) 

2.6.2    Lösung  der  Duffing- Oszillator- Gleichung 
Der  ungedämpfte  Duffing-Oszillator 

Der  Duffing-Oszillator  kann  als  Erweiterung  zum  Harmonischen  Oszillator  angesehen 
werden,  dem  das  lineare  Hooksche  Gesetz  zu  Grunde  liegt  und  eine  kubische  Rück- 
stellkraft  besitzt.  Der  ungedämpfte  und  nicht  angeregte  Duffing-Oszillator  kann  formal 
durch  folgende  gewöhnliche  Differentialgleichung  beschrieben  werden34: 

ü  +  uj%u  +  eu3  =  0  (2.6.105) 
Beispiel  2.13  für  „  Untersuchung  der  Programmlaufzeit" 

Als  erstes  Beispiel  soll  die  Programmlaufzeit  gemessen  werden.  Hierfür  wurden  folgende  AB 
gewählt: 

u(t0  =  0.0)  =  1 
ü(t0  =  0.0)  =  0 

u  =  1  (2.6.106) 

1 

6  _  100 

Die  benötigte  Zeit  At,  die  vergeht,  um  ein  Bewegungsproblem  mit  Hilfe  von  numerischer  Inte- 
gration zu  bestimmen,  hängt  von  der  Plattform  ab,  auf  der  die  Rechnung  durchgeführt  wurde. 
Die  Systemeigenschaften  der  zur  Berechnung  verwendeten  Testplattformen  TP1  und  TP2  sind 
im  Anhang  A.l  auf  der  Seite  183  beschrieben,  sodass  alle  Testszenarien  nachgestellt  wer- 
den können.  Bei  den  durchgeführten  Testrechnungen  wurden  keinerlei  Versuche  unternommen, 
durch  Compileroptimierung  die  Programmlaufzeit  zu  beeinflussen.  Diese  und  weitere  Tech- 
niken zu  Beschleunigung  der  Abarbeitungsgeschwindigkeit  werden  detailliert  in  Abschnitt  5 


siehe  dazu  [Echardt04] 
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untersucht.  Im  Folgenden  wird  die  ungedämpfte  Duffing-Oszillatorgleichung  im  Zeitraum  von 
to  =  0.0  und  tend  =  10.0  Sekunden  mit  verschiedenen  Lösungsverfahren  berechnet  und  deren 
benötigte  Ausführungszeit  beurteilt.  Hierbei  wird  ferner  zwischen  Verfahren  mit  und  ohne  ad- 
aptiver Schrittweitensteuerung  unterschieden. 


[SWS]  Schrittweiten-  Verfahren  ohne  SWS 

Steuerung  diesem  Unterpunkt  werden  die  numerischen  Integrationsverfahren  RK4,  MMID  und  GJ4 

[RK4]  Runge  Kutta  hinsichtlich  ihrer  benötigten  Ausführungszeit  einander  gegenübergestellt.  Hierbei  muss  eine 
^MMff^18  Modified  feste  Schrittweite  h  —  const  vorgegeben  werden.  In  Tabelle  2.7  auf  Seite  46  sind  die  gemes- 
Midpoint  Methode  senen  Programmlaufzeiten  At  in  Abhängigkeit  verschiedener  Datentypen,  Stellengenauigkei- 
[GJ4]  Gauss  Jackson  ten  und  Schrittweiten  eingetragen.  In  der  ersten  Spalte  befindet  sich  der  zur  Berechnung  ver- 
4. Ordnung  wendete  Datentyp.  Beim  Datentyp  long  double  handelt  es  sich  um  den  Standarddatentyp  der 

C-Bibliothek.  Der  bigHoat-Datentyp  entstammt  der  LiDIA-Bibliothek.  Mit  diesem  kann  eine 
beliebige  dezimale  Genauigkeit  gewählt  werden.  In  der  zweiten  Spalte  ist  die  jeweilige  Ge- 
nauigkeit des  Datentyps  eingetragen.  Die  Spalte  Integrator  kennzeichnet  das  zum  Berechnen 
verwendete  Lösungsverfahren  und  die  Spalte  h  enthält  die  jeweils  verwendete  Schrittweite.  Die 
gemessenen  Funktionsaufrufe  sind  in  der  Spalte  Aufrufe '  eingetragen.  Die  gemessene  Ausfüh- 
[TP]  Testplattform       rungszeiten  auf  den  entsprechenden  TP  ist  in  den  Spalten  Ati  und  At2  eingetragen. 


Datentyp 

Genauigkeit 

Integrator 

h 

Aufrufe 

Atx 

At2 

long  double 

19 

RK4 

6.25e-03 

64000 

-  0.126  s 

-0.175  s 

long  double 

19 

RK4 

2.44e-06 

16384000 

—  36.6  s 

-44.7  s 

bigfloat 

19 

RK4 

6.25e-03 

64000 

-2.3  s 

-3.0  s 

bigfloat 

19 

RK4 

2.44e-06 

16384000 

—  10.4  min 

—  12.8  min 

bigfloat 

200 

RK4 

6.25e-03 

64000 

-4.7 s 

-  5.3  s 

bigfloat 

200 

RK4 

2.44e-06 

16384000 

—  18.2  min 

—  22.4  min 

long  double 

19 

MMID 

6.25e-03 

1600 

-  0.007  s 

-  0.003  s 

long  double 

19 

MMID 

2.44e-06 

4096000 

-6.7  s 

-  7.9  s 

bigfloat 

19 

MMID 

6.25e-03 

1600 

-  0.053  s 

-  0.053  s 

bigfloat 

19 

MMID 

2.44e-06 

4096000 

—  1.8  min 

—  2.2  min 

bigfloat 

200 

MMID 

6.25e-03 

1600 

-  0.101  s 

-0.102  s 

bigfloat 

200 

MMID 

2.44e-06 

4096000 

—  3.7  min 

—  4.2  min 

long  double 

19 

GJ4 

6.25e-03 

1616 

-  0.045  s 

-  0.015  s 

long  double 

19 

GJ4 

2.44e-06 

4096016 

-  37.9  s 

-  40.4  s 

bigfloat 

19 

GJ4 

6.25e-03 

1616 

-  0.272  s 

-  0.237  s 

bigfloat 

19 

GJ4 

2.44e-06 

4096016 

—  7.8  min 

—  10.1  min 

bigfloat 

200 

GJ4 

6.25e-03 

1616 

-  0.405  s 

-  0.422  s 

bigfloat 

200 

GJ4 

2.44e-06 

4096016 

—  13.3  min 

—  18.1  min 

Tabelle  2.7:  Gegenüberstellung  der  Lösungsverfahren  ohne  SWS  anhand  ihrer  Aus- 
führungsgeschwindigkeit 


Die  Messergebnisse  in  Tabelle  2.7  lassen  folgende  Schlussfolgerungen  zu: 

•  Unabhängig  vom  verwendeten  Datentyp  ist  das  MMID-Verfahren  bezüglich  der  benö- 
tigten Ausführungszeit  auf  beiden  TP  das  schnellste.  Dies  liegt  an  der  geringeren  An- 

[DG]  Differentialglei-  zahl  an  Funktionsaufrufen  der  rechten  Seite  der  DG.  Dieses  Verfahren  wird  beim  BS- 

chun8  Verfahren  als  Prädiktor  verwendet.  Wie  im  Abschnitt  2.6.1  noch  gezeigt  wird,  erfüllt  das 

MMID-Verfahren  nur  geringe  Genauigkeitsanforderungen  und  stellt  mehr  ein  Hilfsver- 
fahren dar. 

•  Verglichen  mit  GJ4,  zeigt  das  RK4-Verfahren  ein  besseres  Laufzeitverhalten. 
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•  Es  ist  nur  ein  geringer  Unterschied  in  der  Ausführungszeit  zwischen  den  verwendeten 
TP  zu  erkennen. 

Verfahren  mit  SWS 

Um  die  implementierten  Lösungsverfahren  mit  SWS  aufgrund  ihrer  benötigten  Ausführungsge- 
schwindigkeit vergleichen  zu  können,  wurde  die  ungedämpfte  Dufßng-Oszillatorgleichung  mit 
verschiedenen  Datentypen,  Fehlertoleranzen  und  Stellengenauigkeiten  berechnet.  Der  benö- 
tigte Zeitaufwand,  in  Abhängigkeit  der  verwendeten  Konfiguration,  ist  in  der  Tabelle  2.8  auf 
Seite  47  eingetragen.  In  der  Spalte  Integrator  ist  das  zur  Berechnung  verwendete  Lösungsver- 
fahren eingetragen.  Die  verwendeten  Lösungsverfahren  benötigen  zur  automatischen  Schritt- 
weitensteuerung die  Angabe  einer  absoluten  Fehlertoleranz.  Diese  ist  in  der  Spalte  'Toleranz' 
eingetragen.  Die  Anzahl  der  benötigten  Funktionsaufrufe  ist  in  der  Spalte  'Aufrufe'  enthalten. 
Die  Spalten  At\  und  Ai2  enthalten  die  gemessene  Zeit  auf  TP  1  und  TP2  in  Sekunden. 


Datentyp 

Genauigkeit 

Integrator 

Toleranz 

Aufrufe 

Atx 

At2 

long  double 

19 

BS 

1.0e-10 

718 

-  0.027  s 

-  0.011  s 

long  double 

19 

BS 

1.0e-15 

1346 

-  0.037  s 

-  0.014  s 

long  double 

19 

BS 

1.0e-18 

3812 

-  0.054  s 

-0.037  s 

bigfloat 

19 

BS 

1.0e-10 

684 

-  0.275  s 

-  0.233  s 

bigfloat 

19 

BS 

1.0e-15 

1209 

-  0.284  s 

-  0.316  s 

bigfloat 

19 

BS 

1.0e-18 

1981 

-  0.360  s 

-  0.442  s 

bigfloat 

200 

BS 

1.0e-30 

12008 

-6.7 s 

-8.4  s 

bigfloat 

200 

BS 

1.0e-40 

49972 

-  27.4  s 

-31.3  s 

bigfloat 

200 

BS 

1.0e-50 

223579 

—  1.8  min 

—  2.2  min 

bigfloat 

200 

BS 

1.0e-60 

1031313 

—  8.4  min 

—  10.1  min 

long  double 

19 

SG 

1.0e-10 

291 

-  0.004  s 

-  0.002  s 

long  double 

19 

SG 

1.0e-15 

527 

-0.007  s 

-  0.004  s 

long  double 

19 

SG 

1.0e-18 

1429 

-  0.018  s 

-  0.014  s 

bigfloat 

19 

SG 

1.0e-10 

291 

-  0.065  s 

-0.087  s 

bigfloat 

19 

SG 

1.0e-15 

519 

-  0.725  s 

-0.176  s 

bigfloat 

19 

SG 

1.0e-18 

779 

-0.195  s 

-  0.261  s 

bigfloat 

200 

SG 

1.0e-30 

9299 

-4.7  s 

-6.1  s 

bigfloat 

200 

SG 

1.0e-40 

37265 

-  19.4  s 

-  24.5  s 

bigfloat 

200 

SG 

l.Oe-50 

195181 

—  1.7  min 

—  2.3  min 

bigfloat 

200 

SG 

1.0e-60 

1179605 

—  10.4  min 

—  13.3  min 

Tabelle  2.8:  Gegenüberstellung  der  Lösungsverfahren  mit  SWS  anhand  ihrer  Ausfüh- 
rungsgeschwindigkeit 


Die  Betrachtung  der  Ergebnisse  aus  Tabelle  2.8  lässt  folgende  Schlussfolgerung  zu: 

•  Vergleicht  man  das  SG  -  und  das  BS  -  Verfahren  unter  Verwendung  des  long  double 
Datentyps,  so  ist  das  SG-Verfahren  effizienter.  Dies  lässt  sich  auch  an  den  benötigten 
Funktionsaufrufen  ablesen  (siehe  dazu  auch  2.6.2). 

•  Wird  das  SG  -  und  das  BS  -  Verfahren  unter  Verwendung  des  bigüoat-Datentyps  be- 
trachtet, so  ist  das  SG-Verfahren  auf  beiden  TP  schneller  als  das  BS-Verfahren.  Dies  [TP]  Testplattformen 
liegt  an  der  verhältnismäßig  hohen  Anzahl  der  Funktionsaufrufe  des  BS  -  Integrators. 

•  Werden  die  Datentypen  long  double  und  bigfloat  [Genauigkeit  19  Stellen)  hinsichtlich 
der  benötigten  Rechenzeit  betrachtet,  so  fällt  auf,  dass  der  bigfloat  -  Datentyp  mehr 
Rechenzeit  benötigt.  Dies  hat  mehrere  Gründe: 

-  Der  verwaltungstechnische  Mehraufwand  der  bigfloat  -  Klasse  verursacht  einen 
großen  Teil  der  Rechenzeit. 


[SG]  Shampine  Gor- 
don 

[BS]  Burlisch  Stoer 
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-  Die  interne  Darstellung  unterscheidet  sich  im  Vergleich  zu  den  Standarddatenty- 
pen (siehe  3.1.1). 

-  Eine  Gleitkommazahl  wird  innerhalb  der  'bigfloat' -Klasse  mit  Hilfe  von  Integer- 
zahlen dargestellt.  Somit  sind  für  eine  Rechenoperation  mit  dem  'bigfloat'  -  Da- 
tentyp oft  viele  primitive  Rechenoperationen  nötig.  Dadurch  ergibt  sich  ein  ent- 
scheidender Geschwindigkeitsnachteil  gegenüber  den  Standarddatentypen.  In  Ab- 
schnitt 4  befindet  sich  eine  Gegenüberstellung  von  numerischen  Bibliotheken  mit 
frei  wählbarer  Stellengenauigkeit.  Darin  werden  u.a.  Leistungsmessungen  durch- 
geführt. 

Beispiel  2.14  für  „Anzahl  der  Funktionsaufrufe" 

Die  benötigte  Anzahl  der  Funktionsaufrufe  ist  von  entscheidender  Bedeutung,  falls  die  Pro- 
grammlaufzeit eine  Rolle  spielt.  Jede  zusätzliche  Auswertung  der  rechten  Seite  der  Differential- 
gleichung kostet  dabei  Rechenzeit.  Um  diese  so  klein  wie  möglich  zu  halten,  wird  in  diesem 
Abschnitt  die  automatische  Schrittweitensteuerung  und  deren  Verhalten  bei  einer  fest  vor- 
gegeben Aufgabenstellung  untersucht.  Hierfür  wird  analog  zum  vorangegangen  Beispiel  die 
Bewegungsgleichung  des  ungedämpften  Duffing-Oszillators  (siehe  Abschnitt2. 6.2)  zur  Lösung 
verwendet.  Dabei  wird  wieder  im  Intervall  t  €  [0, 10]  Sekunden  integriert,  wobei  die  geforder- 
te absolute  Fehlertoleranz  bei  den  Simulationen  im  Intervall  [\.QE  —  06, 1.0-E  —  15]  variiert 
wurde.  In  Abbildung  2.17  wurden  die  benötigten  Funktionsaufrufe  in  Abhängigkeit  der  jeweils 
eingestellten  und  somit  geforderten  absoluten  Fehlertoleranz  aufgetragen.  Das  SG-Verfahren 
benötigt  für  diese  Aufgabenstellung  deutlich  weniger  Funktionsaufrufe  als  das  BS-Verfahren 
und  ist  somit  effizienter.  Dies  bringt  besonders  bei  sehr  umfangreichen  DG  Vorteile  in  der 
Laufzeit. 
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Abbildung  2.17:  Benötigte  Funktionsaufrufe  in  Abhängig! 
luten  Fehlertoleranz  der  Schrittweitensteuerung 


;keit  der  verwendeten  abso- 


50 


Kapitel  2:  Lösung  gewöhnlicher  Differentialgleichungen 


2.6.3    Hin  -  und  Rückrechnung 


Die  Hin  -  und  Rückrechnung  ist  ein  Mittel  zur  Visualisierung  des  Gesamtfehlers  e^R 
des  jeweiligen  numerischen  Integrationsverfahrens.  Diese  ist  wie  folgt  aufgebaut: 


[AB] 
gung 


[SWS]  Schrittweiten- 
steuerung 


1. 


Hinrechnung: 

Bei  diesem  Schritt  wird  von  einem  Startzeitpunkt  to  zu  einem  Endzeitpunkt  t\ 
integriert. 


/" 

Jt0 


f(t,y(t))dt 


(2.6.107) 


Anfangsbedin- 


Rückrechnung: 

Bei  der  Rückrechnung  werden  die  Ergebnisse  der  Hinrechnung  als  AB  verwen- 
det. Weiter  werden  hier  die  Integrationsgrenzen  vertauscht,  d.h.  es  wird  von  t\ 
nach  to  integriert. 


r 


f(t,y(t))dt 


(2.6.108) 


Der  verursachte  Gesamtfehler  e^R  der  jeweiligen  numerischen  Lösungsverfahren  wird 
durch  Subtraktion  des  Ergebnisses  der  Rückrechnung  mit  den  Anfangswerten  der  Hin- 
rechnung gebildet. 


HR 


y(xQ)  -  Y(x0) 


(2.6.109) 


Im  Folgenden  werden  verschiedene  Verfahren  anhand  des  Gesamtfehlers  gegenüber- 
gestellt. Dabei  wird  zwischen  Verfahren  mit  und  ohne  SWS  unterschieden.  Bei  den 
Verfahren  ohne  SWS  wird  eine  feste  Schrittweite  (h  =  const)  dem  Lösungsverfahren 
vorgegeben. 


2.6.3.1    Verfahren  ohne  SWS 

In  Tabelle  2.9  ist  der  Gesamtfehler  e^R  der  Hin  -  u.  Rückrechnung  eingetragen.  Hier- 
bei wurden  Verfahren  ohne  automatische  SWS  untersucht.  Die  erste  Spalte  kennzeich- 
net den  verwendeten  Datentyp.  In  der  Spalte  'Genauigkeit'  ist  die  Stellengenauigkeit 
des  Datentyps  eingetragen.  Das  verwendete  Lösungsverfahren  ist  in  der  Spalte  'Inte- 
grator' aufgelistet.  Bei  diesen  Verfahren  muss  eine  konstante  Schrittweite  vorgegeben 
werden.  Die  jeweils  verwendete  Schrittweite  ist  in  der  Spalte  'h'  eingetragen.  Die  be- 
nötigten Funktionsaufrufe  sind  der  Spalte  'Aufrufe'  zu  entnehmen. 


Datentyp 

Genauigkeit 

Integrator 

h 

Aufrufe 

fHR 

.9 

long  double 

19 

RK4 

6.25e-03 

128000 

1.36e-17 

long  double 

19 

RK4 

2.44e-06 

32768000 

1.23e-27 

bigfloat 

19 

RK4 

6.25e-03 

128000 

1.35e-17 

bigfloat 

19 

RK4 

2.44e-06 

32768000 

1.23e-27 

bigfloat 

200 

RK4 

6.25e-03 

128000 

1.35e-17 

bigfloat 

200 

RK4 

2.44e-06 

32768000 

1.23e-27 

long  double 

19 

MMID 

6.25e-03 

3200 

3.53e-3 

long  double 

19 

MMID 

2.44e-06 

8192000 

1.41e-6 

bigfloat 

19 

MMID 

6.25e-03 

3200 

3.53e-3 
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bigfloat 

1  C\ 

19 

TV  /Iii  /t  I  T~"\ 

MMID 

A  A  f\f 

2.44e-06 

8192000 

1/11  f 

l.4le-6 

bigfloat 

200 

MMID 

6.25e-03 

3200 

3.53e-3 

bigfloat 

200 

MMID 

2.44e-06 

8192000 

l.41e-6 

long  double 

19 

GJ4 

6.25e-03 

3232 

1.33e-12 

long  double 

19 

GJ4 

2.44e-06 

8192032 

2.17e-19 

bigfloat 

19 

GJ4 

6.25e-03 

3232 

1.33e-10 

bigfloat 

19 

GJ4 

2.44e-06 

8192032 

1.19e-27 

bigfloat 

200 

GJ4 

6.25e-03 

3232 

1.33e-10 

bigfloat 

200 

GJ4 

2.44e-06 

8192032 

1.19e-27 

Tabelle  2.9:  Ergebnisse  der  Hin  -  und  Rückrechnung  der  Duffing  Oszillatorgleichung 
unter  Verwendung  von  Lösungsverfahren  ohne  SWS 

Die  Messergebnisse  aus  Tabelle  2.9  lassen  folgende  Schlussfolgerung  zu: 

•  Werden  die  Verfahren  hinsichtlich  ihres  Gesamtfehlers  e^R  gegenübergestellt, 
so  ist  das  GJ4-Verfahren  geringfügig  besser  als  das  RK4-Verfahren.  Das  MMID- 
Verfahren  ist  dabei  deutlich  schlechter. 

•  Werden  die  benötigten  Funktionsaufrufe  in  die  Betrachtung  miteinbezogen,  so 
ist  das  GJ4  -  Verfahren  am  effizientesten. 

•  Prinzipiell  sind  diese  Verfahren  aufgrund  fehlender  SWS  nicht  für  jede  Problem- 
stellung geeignet.  Sie  werden  jedoch  oft  zur  Berechnung  eines  Anlaufstücks  in 
Pr ädiktor-  Korrektor- Verfahren  eingesetzt. 

2.6.3.2    Verfahren  mit  SWS 

Die  Ergebnisse  der  Hin  -  und  Rückrechnung  mit  Mehrschrittverfahren  sind  in  der  Ta- 
belle 2.10  auf  Seite  52  enthalten.  In  der  ersten  Spalte  ist  der  verwendete  Datentyp 
eingetragen.  Beim  Datentyp  'long  double'  handelt  es  sich  um  den  Standarddatentyp 
der  C-Bibliothek.  Der  'bigfloat'  -  Datentyp  stammt  aus  der  LiDIA-Bibliothek.  Dieser 
erlaubt  eine  frei  wählbare  Stellengenauigkeit.  Die  jeweils  verwendete  Genauigkeit  ist 
in  der  zweiten  Spalte  angegeben.  Die  Spalte  'Integrator'  kennzeichnet  das  verwendete 
numerische  Lösungsverfahren.  In  der  Spalte  'Toleranz'  ist  die  verwendete  Fehlertole-  [SG]  shampine  Gor- 
ranz angegeben,  welche  von  der  automatischen  Schrittweitensteuerung  benötigt  wird  don 

&  &  fe  fe  [BS]  Burlisch  Stoer 

um  den  lokalen  Diskretisierungsfehler  bei  einem  Integrationsschritt  zu  begrenzen.  Die 
fünfte  Spalte  enthält  die  benötigten  Funktionsaufrufe  für  die  Hin  -  u.  Rückrechnung. 
In  der  sechsten  Spalte  ist  verursachte  Gesamtfehler  angegeben. 


Datentyp 

Genauigkeit 

Integrator 

Toleranz 

Funktionsaufrufe 

MR 

long  double 

19 

BS 

1.0e-10 

2698 

~  1.2e-ll 

long  double 

19 

BS 

1.0e-15 

2698 

~  1.2e-16 

long  double 

19 

BS 

1.0e-18 

7376 

~  8.2e-18 

bigfloat 

19 

BS 

1.0e-10 

1355 

~4.0e-10 

bigfloat 

19 

BS 

1.0e-15 

2494 

~  3.5e-15 

bigfloat 

19 

BS 

1.0e-18 

3789 

~  1.6e-18 
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bigfloat 

200 

BS 

1.0e-30 

r\  rs  c\c\c\ 

23999 

~  4.1e-32 

bigfloat 

200 

BS 

1.0e-40 

99158 

~  5.9e-44 

bigfloat 

200 

BS 

1.0e-50 

A  A  c  r\c>  1 

445981 

~  1.9e-43 

bigfloat 

200 

BS 

1.0e-60 

2062146 

~  1.9e-43 

bigfloat 

200 

BS 

1.0e-70 

2914140 

~  1.9e.43 

long  double 

19 

SG 

1.0e-10 

606 

~  7.2e-ll 

long  double 

19 

SG 

1.0e-15 

1215 

~  1.6e-15 

long  double 

19 

l.Ue-lö 

l  110 

~  /.öe-1  / 

bigfloat 

19 

SG 

1.0e-10 

606 

~  7.2e-9 

bigfloat 

19 

SG 

1.0e-15 

1200 

~  1.7e-14 

bigfloat 

19 

SG 

1.0e-18 

1556 

~  6.2e-18 

bigfloat 

200 

SG 

1.0e-30 

18586 

~2.0e-31 

bigfloat 

200 

SG 

1.0e-40 

75838 

~  9.6e-40 

bigfloat 

200 

SG 

1.0e-50 

386110 

~  3.0e-50 

bigfloat 

200 

SG 

1.0e-60 

2331226 

-  3.2e-60 

bigfloat 

200 

SG 

1.0e-70 

13954916 

~  5.2e-70 

Tabelle  2.10:  Ergebnisse  der  Hin  -  und  Rückrechnung  der  Duffing-Oszillatorgleichung 
unter  Verwendung  von  Lösungsverfahren  mit  SWS 


Aus  den  Ergebnissen  der  Hin  -  und  Rückrechnung  lassen  sich  folgende  Schlussfol- 
gerungen ableiten: 

•  Das  Anwachsen  des  Rundungsfehlers  kann  nicht  vermieden  werden.  Die  einzi- 
ge Möglichkeit  liegt  darin,  die  Stellengenauigkeit  zu  erhöhen.  Dies  rechtfertigt 
den  Einsatz  von  numerischen  Bibliotheken  mit  einstellbarer  Stellengenauigkeit 
(siehe  Abschnitt  4  auf  Seite  87). 

•  Die  verwendete  Stellengenauigkeit  der  C-Standardbibliothek  reicht  nicht  aus, 
falls  über  einen  längeren  Zeitraum  integriert  wird,  da  der  Gesamtfehler  zu  stark 
anwächst. 

•  Das  Lösungsverfahren  von  SG  ist  bezüglich  der  benötigten  Funktionsaufrufe 
effizienter  als  das  BS-Verfahren.  Es  ist  somit  bei  umfangreichen  Differential- 
gleichungen zu  bevorzugen,  wie  es  bei  der  Berechnung  der  Kraftfunktion  eines 
Satelliten  innerhalb  des  Gravitationsfeldes  der  Erde  der  Fall  ist. 

•  Betrachtet  man  den  Gesamtfehler  e^R  m  Abhängigkeit  der  verwendeten  Feh- 
lertoleranz genauer,  so  fällt  auf,  dass  beim  BS-Verfahren  dieser  zu  ~1.9e-43 
konvergiert.  Beim  SG- Verfahren  hingegen  bleibt  eg  unter  der  gewünschten  Feh- 
lertoleranz. Somit  ist  das  BS-Verfahren  für  Berechnungen  mit  einer  geforderten 
Fehlertoleranz  >  1.0e-50  ungeeignet  und  das  SG- Verfahren  zu  bevorzugen. 

•  Bei  Toleranzanforderungen  ~<  l.Oe  —  43  ist  das  BS-Verfahren  zu  bevorzugen. 
Es  benötigt  zur  Lösung  zwar  mehr  Funktionsaufrufe  als  das  SG- Verfahren,  dafür 
ist  e^R  kleiner. 
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Um  sicher  zu  gehen,  dass  die  implementierten  Lösungsverfahren  korrekt  arbeiten, 
wurden  Testrechnungen  erstellt  und  diese  von  Herrn  Mai  mit  Hilfe  seiner  in  MATHE- 
MATICA35  implementierten  Lösungsverfahren  verifiziert.  Darüber  hinaus  wurde  die 
analytische  Lösung  des  ungedämpften  Duffing-Oszillators  (30.Ordnung36)  im  Rahmen 
dieser  Arbeit  in  C++  implementiert.  Diese  wurde  u.A.  zur  Verifikation  der  Lösungs- 
verfahren herangezogen. 


2.6.3.3    Vergleich  von  Einschritt-Mehrschrittverfahren 

Im  Folgenden  werden  Vor  -  u.  Nachteil  der  Ein  -  u.  Mehrschrittverfahren  angegeben. 
vorteile  der  Einschrittverfahren 

•  Diese  Verfahren  sind  selbststartend,  d.h.  sie  benötigen  keine  weiteren  Hilfsver- 
fahren zur  Berechnung  eines  Anlaufstücks,  wie  dies  bei  Mehrschrittverfahren 
der  Fall  ist. 

•  Die  Integrationsschrittweite  kann  für  jeden  Integrationsschritt  frei  gewählt  wer- 
den. 

•  Die  Schrittweite  kann  an  die  Anforderungen  der  Differentialgleichung  angepasst 
werden. 

•  Mit  embedded  Runge- Kutta- Verfahren  ist  es  möglich,  den  lokalen  Diskretisie- 
rungsfehler  zu  überwachen  und  so  eine  adaptive  Schritt weitensteuerung  einzu- 
führen, sodass  diese  bei  jeden  Integrationsschritt  passend  gewählt  wird37. 

Nachteile  von  Einschritt  verfahren: 

•  Sie  besitzen  eine  kleinere  Konsistenzordnung  im  Vergleich  zu  Prädiktor- Korrektor- 
Verfahren. 

•  Die  Konsistenzordnung  ist  durch  das  Verfahren  vorgegeben.  Soll  diese  geändert 
werden,  so  muss  das  Verfahren  geändert  werden. 

•  Eine  Erhöhung  der  Konsistenzordnung  bringt  mehr  Auswertungen  der  Differen- 
tialgleichung mit  sich. 

•  Um  die  Genauigkeit  zu  erhöhen,  ist  es  erforderlich,  die  Schrittweite  h  zu  ver- 
kleinern. Dadurch  treten  jedoch  mehr  Rundungsfehler  er  auf. 

•  Verglichen  mit  den  Prädiktor- Korrektor- Verfahren  sind  bei  diesen  Verfahren  mehr 
Auswertungen  der  Differentialgleichung  pro  Integrationsschritt  nötig. 

•  Es  ist  keine  brauchbare  Fehlerabschätzung  angebbar38. 


siehe  dazu  [Mathematica] 
siehe  dazu  [Maill] 

siehe  dazu  [Montenbruck05]  und  [Press92] 
siehe  dazu  [Jordan72] 
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Vorteile  von  Mehrschritt  verfahren: 

•  Es  sind  pro  Integrationsschritt  nur  zwei  Auswertungen  der  Differentialgleichung 
nötig.  Dies  ist  ein  Prädiktor-Schritt  und  pro  Iteration  ein  Korrektor-Schritt. 

•  Die  Ordnung  des  Verfahrens  kann  angepasst  werden. 

•  Durch  adaptive  Schrittweitensteuerung  und  integrierte  Fehlerabschätzung  wird 
der  lokale  Diskretisierungsfehler  unter  einer  vorgegebenen  Schranke  gehalten. 

•  Treten  Diskontinuitäten  während  der  Integration  auf,  dann  beginnt  das  Verfahren 
erneut,  indem  ein  neues  Anlaufstück  berechnet  wird. 

Nachteile  von  Mehrschrittverfahren: 

•  Ergibt  sich  eine  Änderung  der  Schrittweite,  so  müssen  die  vorherigen  Punk- 
te neu  berechnet  werden.  Tritt  dieser  Fall  häufig  ein,  so  steigt  die  Anzahl  der 
Funktionsaufrufe  und  was  sich  wiederum  negativ  auf  das  Laufzeitverhalten  aus- 
wirkt. 

[AW]  Anfangswerte  •  Die  AW  müssen  mit  Hilfe  eines  Einschrittverfahrens  ermittelt  werden. 

2.6.4    Integration  von  Satellitenbahnen 

Aufgrund  der  stetig  verbesserten  Messgenauigkeit  geodätischer  Raumverfahren  wer- 
den auch  höhere  Anforderung  an  die  numerischen  Lösungsverfahren,  welche  zur  Si- 
mulation von  Satellitenbahnen  benötigt  werden,  gestellt.  In  diesem  Abschnitt  soll  am 
Beispiel  von  zwei  Standardproblemen  die  erreichbare  numerische  Genauigkeit,  in  Ab- 
hängigkeit verschiedener  Randbedingungen,  verifiziert  werden.  Um  höhere  Genauig- 
keiten bei  der  Simulation  zu  erreichen,  können  muitiprecision-Bibliotheken  zur  Be- 
rechnung verwendet  werden.  Dies  ist  mit  zusätzlichem  Rechenzeitaufwand  verbun- 
den und  soll  abgeschätzt  werden.  Zur  Lösung  von  Differentialgleichungen  gibt  es  eine 
Vielzahl  verschiedener  Verfahren,  aus  denen  für  diese  Untersuchung  einige  relevante 
ausgewählt  wurden. 

Das  Keplerproblem 

Die  folgenden  Variablen  werden  als  gegeben  vorausgesetzt: 

y/x2{t)+y2{t)+z2{t). 

dr  =  2z  (t)  {jz  (t))  +  2y  (t)  (£y  (t))  +  2x  (t)  (&x  (t))  =  [rf\_ 
dt  2^z2  (t)  +  y2(t)  +  x*  (t)  r  ' 


dabei  ist 

•  r  der  Ortsvektor  im  Inertialsystem  und  r  die  geometrische  Distanz. 


x{t)\ 
r=    y(t)    ;  r  = 
\z(t)J 

fx(t)\ 
r=    y(t)    ;  r  = 

\mJ 

a  =  GMff,; 
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•  f  der  Vektor  der  Geschwindigkeitskomponenten  und  r  die  Radialgeschwindig- 
keit. 

•  fi  die  Gravitationskonstante  G  multipliziert  mit  der  Masse  der  Erde  M®. 

•  t  die  Zeit. 


Hinweise  zur  Notation 

Der  Ausdruck  [ab]  entspricht  dem  Skalarprodukt  zweier  Vektoren,  d.h.  [ab]  :=  ao&o  +  ••■  +  anb. 
Wobei  die  Vektoren  a  und  b  aus  n  +  1  Komponenten  bestehen. 

Diese  Notation  ist  insbesondere  zur  Kontrolle  der  Dimension  größerer  Ausdrücke  hilfreich. 


Die  Keplerellipse  besitze  eine  Halbachse  von  a  =  10000  Kilometer  mit  einer  Exzen- 
trizität e  =  \,  wodurch  die  Umlaufzeit  bei  etwa  zwei  Stunden  (5614  Sekunden)  liegt. 
Für  alle  folgenden  Berechnungen  wurden  die  Anfangswerte  aus  Tabelle  2.12  verwen- 
det, welche  hierfür  aus  den  Keplerschen-Bahnelementen  in  kartesische  Koordinaten 
umgewandelt  wurden. 


Komponente 

numerischer  Wert 

Einheit 

x(t0) 

-4461.254589873326 

[km] 

y(to) 

6652.161968871405 

[km] 

z(to) 

1371.264327186286 

[km] 

x(t0) 

-7.282787778641558 

[km/s] 

y(to) 

-2.280408476437688 

[km/s] 

z(to) 

0.006135775178224878 

[km/s] 

Tabelle  2.12:  Anfangswerte,  die  zur  Berechnung  verwendet  wurden 


Für  einen  ersten  Test  der  Integrationsverfahren  wird  im  folgenden  Beispiel  über  einen 
Zeitraum  von  5614  Sekunden  (ein  Umlauf)  integriert. 

Beispiel  2.15  für  „Integration  über  einen  Umlauf  (5614  Sekunden)" 

Hierfür  wurden  drei  Verfahren  mit  adaptiver  Schrittweitensteuerung  ausgewählt:  BS,  SG  und 
DOP.  Bei  diesen  Verfahren  muss  eine  absolute  und  relative  Fehlerschranke  sowie  eine  definier- 
te Ausgabeschrittweite  vorgegeben  werden.  Die  einstellbare  Ausgabeschrittweite  ist  für  den 
Vergleich  der  verschiedenen  Verfahren  erforderlich,  um  Stützstellen  zu  definierten  Zeitpunkten 
zu  erhalten.  Ansonsten  müssten  die  jeweiligen  Stützstellen  nachträglich  interpoliert  werden. 
Davon  wurde  hier  abgesehen,  da  darin  zusätzliches  Fehlerpotential  liegt.  Zur  Darstellung  der 
Gleitkommazahlen  wurden  die  Standarddatentypen  double  und  long  double  mit  einer  Maschi- 
nengenauigkeit von  1.0e-16  bzw.  1.0e-19  verwendet.  Näheres  dazu  und  weitere  Informationen 
können  im  Abschnitt  3  nachgeschlagen  werden. 

In  den  Tabellen  2.13  und  2.14  sind  die  Ergebnisse  für  den  Simulationszeitraum  eines  vollstän- 
digen Umlaufs  dargestellt  und  nach  Integrationsverfahren  sortiert.  Darin  wird  jedem  Verfahren 
eine  Spalte  zugeordnet,  worin  die  Anzahl  der  benötigten  Funktionsaufrufe  C  und  ein  mittlerer 
Fehler  -  pro  Integrationsschritt  -  eingetragen  ist.  Letzterer  ist  wie  folgt  definiert: 
Falls  C  Funktionsaufrufe  notwendig  sind  und  n  absolute  Fehlerwerte  im  Zeitintervall  [t\,  tn] 
bestimmt  wurden,  wird  TTC  wie  folgt  berechnet: 
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£^tabs{U)  (2.6.110) 

i— 1 

Damit  kennzeichnet  T~c  den  mittleren  absoluten  Fehler,  welcher  durchschnittlich  pro  Funktions- 
aufrufbegangen wird.  Dies  ist  somit  eine  Kennzahl  für  die  jeweilige  Güte  der  durchgeführten 
Berechnung.  Ferner  ist  jeder  Zeile  eine  absolute  Fehlertoleranz  zugeordnet  (links),  die  als  Vor- 
gabe an  das  Integrationsverfahren  übergeben  wurde.  Zusätzlich  ist  die  Entwicklung  der  Funk- 
tionsaufrufe sowie  der  kumulative,  absolute  Fehler  in  Abhängigkeit  der  jeweils  vorgegebenen 
Fehlerschranke  in  Abb.  2.18  und  in  Abb.  2.19  illustriert.  Dort  fällst  auf  dass  der  SG-Integrator 
sowohl  beim  double,  als  auch  beim  long  double  Datentyp  nahezu  gleiche  Anzahl  Funktions- 
aufrufe benötigt,  jedoch  beim  long  double-Datentyp  einen  wesentlich  geringeren  kumulativen 
Fehler  aufweist.  Außerdem  ist  der  Funktionsverlauf  der  Experimente  mit  dem  double  bzw.  long 
double-Datentype  in  vielen  Fällen  ähnlich. 


BS 

SG 

DOPRI 

AbsTol 

C 

-rr-  r     mm  j 

C 

-jr-  r     mm  j 

C 

-r-  r     mm  7 

tc  '  Aufruf  J 

tc  '  Aufruf  > 

fcc  '  Aufruf 1 

1E-04 

78626 

1.25E-05 

60333 

0.08355 

101086 

5.01E-06 

1E-05 

78626 

1.25E-05 

78263 

0.00230 

101086 

5.01E-06 

1E-06 

78626 

1.25E-05 

97207 

1.90E-05 

101086 

5.01E-06 

1E-07 

78626 

1.24E-05 

114823 

1.33E-05 

101086 

5.01E-06 

1E-08 

78751 

1.09E-05 

134199 

3.54E-06 

101086 

5.01E-06 

IE-09 

79744 

1.55E-05 

152859 

1.34E-05 

101086 

5.01E-06 

1E-10 

87188 

9.07E-06 

170731 

6.03E-06 

101086 

5.01E-06 

1E-11 

111509 

1.32E-05 

190261 

6.41E-06 

101086 

5.01E-06 

1E-12 

112694 

1.21E-05 

208711 

4.46E-05 

101086 

5.01E-06 

1E-13 

115484 

1.79E-05 

226751 

7.26E-06 

101086 

5.01E-06 

1E-14 

133516 

2.46E-05 

248573 

2.13E-06 

101086 

5.08E-06 

1E-15 

146110 

2.28E-05 

264763 

7.33E-06 

101092 

5.41E-06 

Tabelle  2.13:  Mittlerer  absoluter  Fehler  pro  Funktionsaufruf  und  Anzahl  benötigter 
Funktionsaufrufe  für  den  Integrationszeitraum  eines  Umlaufs  unter  Verwendung  des 
double-Datentyps 


Bei  der  Berechnung  eines  Umlaufs  ist  zu  beobachten,  dass  sich  die  entsprechenden  Fehler  in 
Abhängigkeit  des  verwendeten  Verfahrens  unterschiedlich  stark  akkumulieren.  Dennoch  kann 
hier  schon  ein  Trend  erkannt  werden:  Mit  zunehmender  Integrationszeit  werden  mehr  Funkti- 
onsaufrufe benötigt,  was  neben  den  Verfahrensfehler  auch  einen  Anstieg  des  Rundungsfehlers 
verursacht.  Dies  soll  im  nächsten  Beispiel,  bei  dem  über  einen  Integrationszeitraum  von  einem 
Tag  integriert  wird,  weiter  untersucht  werden. 


BS 

SG 

DOPRI 

AbsTol 

C 

-r-  r     mm  j 

C 

-r-  r     mm  j 

C 

-pr-  r     mm  j 

tc  L  Au  fru  f  1 

tc  L  Aufruf  J 

tc  '  Aufruf  J 

1E-04 

78626 

7.75E-07 

60333 

0.08355 

101086 

2.82E-09 

1E-05 

78626 

7.75E-07 

78263 

0.00233 

101086 

2.82E-09 

1E-06 

78626 

7.75E-07 

97207 

5.71E-05 

101086 

2.82E-09 
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1E-07 

78633 

7.75E-07 

114823 

1.41E-06 

101086 

2.82E-09 

1E-08 

78751 

7.61E-07 

134199 

8.80E-09 

101086 

2.82E-09 

1E-09 

79744 

7.48E-07 

152859 

4.90E-09 

101086 

2.82E-09 

1E-10 

87188 

2.97E-07 

170731 

1.16E-08 

101086 

2.82E-09 

1E-11 

111405 

6.87E-09 

190261 

1.24E-08 

101086 

2.82E-09 

1E-12 

112694 

8.16E-09 

208711 

2.97E-09 

101086 

2.82E-09 

1E-13 

115484 

8.38E-09 

226725 

1.61E-08 

101086 

2.82E-09 

1E-14 

179348 

1.88E-09 

247713 

3.03E-07 

101086 

2.82E-09 

1E-15 

146014 

1.56E-09 

273207 

1.40E-07 

101086 

2.82E-09 

1E-16 

146030 

1.56E-09 

300821 

1.48E-08 

101086 

2.88E-09 

1E-17 

146152 

1.79E-09 

329361 

1.87E-09 

101098 

2.84E-09 

1E-18 

147938 

2.98E-09 

355385 

4.56E-10 

101266 

2.83E-09 

Tabelle  2.14:  Mittlerer  absoluter  Fehler  pro  Funktionsaufruf  und  Anzahl  benötigter 
Funktionsaufrufe  für  den  Integrationszeitraum  eines  Umlaufs  unter  Verwendung  des 
long  double-Datentyps 


10000 


0,0001   1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  

0.01  0.0001  le-06  le-OB  le-10  le-12  le-14  le-16  le-lB 

absolute  Fehlertoleranz 


Abbildung  2.18:  Kumulativer  absoluter  Fehler  bei  einer  geforderten  Genauigkeit  (Ab- 
sTol)  und  einem  Umlauf 
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Abbildung  2.19:  Anzahl  der  benötigten  Funktionsaufrufe  für  einen  Umlauf  in  Abhän- 
gigkeit der  eingestellten  Genauigkeit  (AbsTol) 


Beispiel  2.16  für  „Untersuchung  zum  Simulationszeitraum  von  einem  Tag  (15  Umläufe)" 

In  diesem  Beispiel  wurde  der  Integrationszeitraum  auf  einen  Tag  erweitert.  Dies  entspricht 
bei  der  hier  verwendeten  Bahnkonfiguration  etwas  mehr  als  15  Umläufen.  Dieses  Experiment 
soll  den  Verlauf  des  Fehlers  für  diese  Zeitspanne  ermitteln,  um  die  verwendeten  Integrations- 
verfahren besser  beurteilen  zu  können.  Betrachtet  man  den  Verlauf  des  kumulativen  Fehlers 
in  Abhängigkeit  von  der  jeweils  geforderten  Genauigkeit  (Abb.2.20)  für  den  Fall  des  double- 
Datentyps,  so  ist  das  SG-Verfahren  bei  der  maximal  geforderten  Genauigkeit  von  1.0E-15  das 
Verfahren  mit  dem  kleinsten  Fehler.  Aus  Tabelle  2.15  ist  jedoch  abzulesen,  dass  dafür  die  mei- 
sten Funktionsaufrufe  nötig  sind.  Falls  der  long  double-Datentyp  verwendet  und  ebenfalls  die 
maximal  geforderte  Genauigkeit  von  1.0E-18  betrachtet  wird,  so  ist  hier  das  SG-Verfahren  be- 
züglich seiner  Fehlerakkumulation  das  bessere  Verfahren.  Hervorzuheben  ist  jedoch  hier  die 
vergleichsweise  hohe  Anzahl  von  Funktionsaufrufen  (siehe  Tab.  2.16),  die  bei  umfangreicheren 
Differentialgleichungen  zu  Problemen  bei  der  Abarbeitungsgeschwindigkeit  führen  können.  Im 
Allgemeinen  kann  für  diesen  Zeitraum  das  SG-Verfahren  empfohlen  werden,  falls  die  Laufzeit 
eine  untergeordnete  Rolle  spielt,  aber  auf  Genauigkeit  Wert  gelegt  wird.  Falls  die  Programm- 
laufzeit wichtig  ist,  scheint  das  BS-Verfahren  ein  guter  Kompromiss  zwischen  Aufwand  und 
Genauigkeit  zu  sein. 


BS 

SG 

DOPRI 

AbsTol 

C 

-rr-  r     mm  7 

C 

-r-  f     mm  7 

C 

■jr-  r     mm  7 

tc  '  Aufruf  1 

&c  '  Aufruf  1 

tc  '  Aufruf  ' 

1E-04 

181456 

6.16E-02 

152872 

4.80E-01 

207376 

3.53E-04 

1E-05 

181743 

6.16E-02 

180358 

2.19E-02 

207376 

3.53E-04 

1E-06 

185611 

7.82E-02 

209928 

2.81E-01 

207376 

3.53E-04 

1E-07 

203612 

3.16E-02 

238710 

1.18E-01 

207376 

3.53E-04 

1E-08 

232850 

2.60E-04 

266388 

1.19E-01 

207376 

3.53E-04 

1E-09 

239696 

1.36E-04 

296208 

3.55E-01 

207376 

3.53E-04 
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1E-10 

264869 

9.26E-05 

326246 

4.69E-03 

207376 

3.53E-04 

1E-11 

366804 

9.77E-05 

368889 

2.35E-02 

207376 

3.53E-04 

1E-12 

288726 

1.10E-04 

421333 

1.15E-03 

207448 

3.68E-04 

1E-13 

310310 

9.35E-05 

470748 

7.57E-05 

209878 

3.51E-04 

1E-14 

362176 

1.00E-04 

520312 

1.86E-05 

226814 

1.28E-04 

1E-15 

411008 

1.32E-04 

554155 

1.04E-05 

263122 

1.63E-04 

Tabelle  2.15:  Mittlerer  absoluter  Fehler  pro  Funktionsaufruf  und  Anzahl  benötig- 
ter Funktionsaufrufe  für  den  Integrationszeitraum  eines  Tages  unter  Verwendung  des 
double-Datentyps 


Abbildung  2.20:  Kumulativer  absoluter  Fehler  über  verlangter  Genauigkeit  (AbsTol) 
bei  einem  Tag 


BS 

SG 

DOPRI 

AbsTol 

C 

-jr-  r     mm  j 

C 

—  r     mm  7 

C 

-pr-  r    mm  j 

tc  '  Aufruf  1 

fcc  '  Aufruf  1 

tc  '  Aufruf 1 

1E-04 

181456 

6.19E-02 

152872 

4.78E-02 

207376 

2.61E-04 

1E-05 

181743 

6.17E-02 

180358 

5.00E-03 

207376 

2.61E-04 

1E-06 

185611 

7.83E-02 

209928 

1.36E-03 

207376 

2.61E-04 

1E-07 

203612 

3.18E-02 

238710 

9.21E-03 

207376 

2.61E-04 

1E-08 

232850 

1.75E-04 

266386 

6.46E-02 

207376 

2.61E-04 

1E-09 

239696 

3.57E-06 

296134 

3.47E-02 

207376 

2.61E-04 

1E-10 

264869 

5.36E-07 

324792 

8.38E-03 

207376 

2.61E-04 

1E-11 

298774 

1.73E-07 

353847 

1.89E-03 

207376 

2.61E-04 

1E-12 

299726 

4.98E-07 

389204 

5.81E-04 

207448 

2.61E-04 
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1E-13 

325293 

4.06E-07 

432054 

6.28E-05 

209878 

2.55E-04 

1E-14 

453858 

7.67E-08 

506577 

1.55E-05 

226819 

9.56E-06 

1E-15 

402584 

1.82E-07 

570239 

2.02E-06 

262820 

1.73E-06 

1E-16 

406520 

1.35E-07 

623165 

8.36E-08 

315775 

1.41E-07 

1E-17 

411610 

1.54E-07 

676719 

2.38E-08 

408142 

8.37E-08 

1E-18 

459779 

8.14E-08 

736662 

2.20E-08 

566842 

7.51E-08 

Tabelle  2.16:  Mittlerer  absoluter  Fehler  pro  Funktionsaufruf  und  Anzahl  benötigter 
Funktionsaufrufe  für  den  Integrationszeitraum  eines  Tages  unter  Verwendung  des  long 
double-Datentyps 


BS,  double 
BS,  long  double 
SG,  double 
SG,  long  double 
DOP,  double 
DOP,  lang  double 

0.0001  1 


le-10  le-12 
absolute  Fehlertoleranz 


Abbildung  2.21:  Anzahl  der  Funktionsaufrufe  bei  der  Integration  über  einen  Zeitraum 
von  einem  Tag 


Beispiel  2.17  für  „Untersuchung  zum  Simulationszeitraum  von  einer  Woche  (ca.  108  Um- 
läufe)" 

In  diesem  Experiment  wird  wieder  das  Keplerproblem  integriert,  wobei  der  Integrationszeit- 
raum auf  eine  Woche  ausgedehnt  wird.  Ziel  ist  es,  die  Stabilität  der  verwendeten  Integratoren 
für  diesen  relativ  langen  Zeitraum  zu  beurteilen. 
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BS,  double  — i — 
BS,  long  double  — * — 
SG,  double  — * — 
SG,  long  double  — b — 
DOP,  double  — ■ — 
DOP,  long  double  — a — 

0.0001  le-06  le-OB  le-10  le-12  le-14  le-16  le-lB 

absolute  Fehlertoleranz 

Abbildung  2.22:  Anzahl  der  Funktionsaufrufe  bei  der  Integration  über  einen  Zeitraum 
von  7  Tagen  Integrationszeit 

Betrachtet  man  die  Anzahl  der  benötigten  Funktionsaufrufe  (Abb.  2.22),  so  fällt  auf,  dass  ana- 
log zu  den  beiden  vorangegangen  Experimenten  das  SG-Verfahren,  unabhängig  vom  verwen- 
deten Datentyp,  am  meisten  Funktionsaufrufe  benötigt.  Hinsichtlich  tatsächlich  erzielter  Ge- 
nauigkeit ist  das  SG-Verfahren  sowohl  beim  double  als  auch  beim  long  double-Datentyp,  das 
Verfahren  mit  der  kleinsten  Fehlerakkumulation.  Jedoch  ist  allgemein  betrachtet,  die  Größen- 
ordnung des  kumulativen  Fehlers  sogar  beim  SG-Verfahren  im  Millimeterbereich. 


BS 

SG 

DOPRI 

AbsTol 

C 

—  r     mm  7 

C 

—  r     mm  7 

C 

—  r     mm  7 

£c  '  Aufruf  ' 

e°  '  Aufruf  1 

tc  l  Aufruf' 

1E-04 

1270096 

7.01E-01 

577051 

2.26E+01 

1451536 

2.35E-02 

1E-05 

1272483 

6.19E-01 

1071082 

1.08E+00 

1451536 

2.35E-02 

1E-06 

1300456 

6.28E-01 

1263552 

1.45E+01 

1451536 

2.35E-02 

1E-07 

1429507 

1.36E+00 

1470654 

9.84E+01 

1451536 

2.35E-02 

1E-08 

1630881 

1.96E-02 

1672054 

6.09E+01 

1451536 

2.35E-02 

1E-09 

1679656 

8.31E-03 

1865802 

1.91E+01 

1451536 

2.35E-02 

1E-10 

1859907 

7.40E-03 

2074674 

2.29E-01 

1451536 

2.35E-02 

1E-11 

2572245 

3.49E-03 

2284608 

5.74E-01 

1451536 

2.35E-02 

1E-12 

2019722 

9.68E-03 

2585813 

1.04E-01 

1452268 

2.31E-02 

1E-13 

2179906 

7.79E-03 

2953427 

1.46E-03 

1469740 

2.26E-02 

1E-14 

2540070 

1.08E-02 

3301553 

9.49E-04 

1592658 

9.62E-03 

1E-15 

2818892 

1.02E-02 

3649210 

2.88E-05 

1849884 

8.59E-03 

Tabelle  2.17:  Mittlerer  absoluter  Fehler  pro  Funktionsaufruf  und  Anzahl  benötigter 
Funktionsaufrufe  für  den  Integrationszeitraum  von  einer  Woche  unter  Verwendung  des 
double-Datentyps 
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0.1    1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  

0.01  0.0001  le-06  le-OB  le-10  le-12  le-14  le-16  le-lB 

absolute  Fehlertoleranz 


Abbildung  2.23:  Kumulativer  absoluter  Fehler  bei  einer  geforderten  Genauigkeit  (Ab- 
sTol)  und  7  Tagen  Integrationszeit 


BS 

SG 

DOPRI 

AbsTol 

C 

r     mm  7 

C 

r     mm  7 

C 

r     mm  7 

tc  '  Aufruf-1 

tc  '  Aufruf-1 

tc  '  Aufruf-1 

1E-04 

1270096 

6.90E-01 

1071082 

2.26E+01 

1451536 

1.52E-02 

1E-05 

1272483 

6.07E-01 

1263552 

2.19E-01 

1451536 

1.52E-02 

1E-06 

1300456 

6.40E-01 

1470654 

4.20E-02 

1451536 

1.52E-02 

1E-07 

1429507 

1.37E+00 

1672054 

4.09E-01 

1451536 

1.52E-02 

1E-08 

1630881 

8.38E-02 

1865798 

3.77E+00 

1451536 

1.52E-02 

1E-09 

1679656 

8.03E-05 

2074076 

1.91E+01 

1451536 

1.52E-02 

1E-10 

1859933 

2.63E-05 

2274624 

6.10E-01 

1451536 

1.52E-02 

1E-11 

2089943 

7.02E-06 

2478495 

1.39E-01 

1451536 

1.52E-02 

1E-12 

2102126 

2.79E-05 

2728139 

3.78E-02 

1452268 

1.52E-02 

1E-13 

2287440 

4.56E-06 

3029628 

1.61E-03 

1469794 

1.48E-02 

1E-14 

3185356 

4.16E-06 

3551863 

6.83E-04 

1592783 

1.02E-04 

1E-15 

2818784 

9.33E-07 

3997471 

9.89E-05 

1846973 

9.53E-05 

1E-16 

2845240 

1.79E-06 

4369635 

4.82E-06 

2221644 

1.19E-05 

IE- 17 

2877952 

1.28E-06 

4745828 

8.79E-08 

2879014 

2.64E-06 

1E-18 

3122878 

1.24E-06 

5167584 

1.67E-07 

4003223 

1.46E-06 

Tabelle  2.18:  Mittlerer  absoluter  Fehler  pro  Funktionsaufruf  und  Anzahl  benötigter 
Funktionsaufrufe  für  den  Integrationszeitraum  von  einer  Woche  unter  Verwendung  des 
long  double-Datentyps 
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2.6.5    Fazit  zur  Integration  von  Satellitenbahnen  mit  herkömmlicher  Ge- 
nauigkeit 

Die  durchgeführten  Experimente  haben  gezeigt,  dass  bei  einer  relativ  einfachen  Pro- 
blemstellung, wie  dem  Keplerproblem,  die  Resultate  der  hier  untersuchten  Integra- 
tionsverfahren durchaus  große  Unterschiede  aufweisen.  Es  wurde  gezeigt,  dass  bei 
einem  Integrationszeitraum  von  einer  Woche  eine  Ungenauigkeit  von  einem  Millime- 
ter39 nur  mit  einem  der  drei  verwendeten  Verfahren  eingehalten  werden  konnte.  In 
einer  umfangreicheren  Simulation  einer  Satellitenbahn,  bei  der  beispielsweise  Kräfte 
wie  der  Strahlungsdruck  der  Sonne  und  die  Erdanziehungskraft  miteinbezogen  wer- 
den, fallen  signifikant  mehr  Rechenoperationen  pro  Integrationsschritt  an.  Diese  resul- 
tieren in  einem  Anstieg  des  Rundungsfehlers,  der  das  Ergebnis  zusätzlich  verschlech- 
tert. Somit  sind  die  hier  durchgeführten  Experimente  als  Minimalbeispiele  zu  betrach- 
ten, deren  Ergebnis  durch  mehr  Rechenoperation  verschlechtert  und  keinesfalls  ver- 
bessert wird.  Soll  über  einen  Zeitraum  von  einer  Woche  hinaus  integriert  werden  und 
sind  höhere  Anforderungen  an  die  Genauigkeit  gestellt,  so  empfiehlt  sich  der  Einsatz 
von  Datentypen  mit  mehrfacher  Genauigkeit. 


siehe  dazu  auch  in  Anhang  F.3  auf  Seite  219,  wo  die  Entwicklung  des  absoluten  Fehlers  über  den 
Simulationszeitraum  von  sieben  Tagen  aufgetragen  ist.  Hierbei  wird  ebenfalls  bestätigt,  dass  nach  einer 
Woche  Simulationsdauer  höchstens  ein  Millimeter  Genauigkeit  gefordert  werden  kann. 
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Kapitel  3 

Implementierungsaspekte 


Schwerpunkt  des  Kapitels: 

In  diesem  Abschnitt  wird  die  interne  Darstellung  von  Gleitkommazahlen  und  ihr  Run- 
dungsverhalten diskutiert.  Darauf  aufbauend  wird  neben  einigen  anderen  Beispielen 
eine  Rundungsfehleranalyse  der  Duffing-  Oszillatorgleichung  durchgeführt.  Schließ- 
lich soll  kurz  auf  die  Konzepte  der  objektorientierten  Programmierung  und  die  pro- 
grammiertechnische Umsetzung  eingegangen  werden.  Diese  Hinführung  zum  Thema 
der  objektorientierten  Programmierung  wird  benötigt,  um  während  der  Entwicklung 
der  Lösungsverfahren  getroffene  Designentscheidungen  besser  nachvollziehen  zu  kön- 
nen. Einige  Hauptmerkmale  daraus  sind: 

•  Das  Klassenkonzept 

•  Das  Konzept  der  Kapselung 

•  Das  Vererbungskonzept 

•  Die  Operatorüberladung 

•  Die  Template-Programmierung 

Im  Anschluss  wird  mit  Hilfe  von  Quelltextauszügen  die  programmiermäßige  Vorge- 
hensweise zur  Lösung  einer  Differentialgleichung  schrittweise  erklärt. 
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3.1  Gleitkommazahlen 

Die  Entwicklung  des  Gleitkommazahlenformats  ist  historisch  gesehen  die  Antwort  auf 
die  Frage,  welches  Maschinenformat  für  die  Darstellung  reeller  Zahlen  notwendig  ist, 
um  alle  vier  Grundrechenarten  (Addition,  Subtraktion,  Multiplikation  und  Division) 
möglichst  performant  durchführen  zu  können1.  Die  interne  Binärdarstellung  erlaubt 
die  effiziente  Durchführung  von  Addition  und  Subtraktion.  Die  Multiplikation  und 
Division  kann  mit  Hilfe  von  logarithmischer  Zahlendarstellung  auf  Addition  und  Sub- 
traktion zurückgeführt  werden,  wie  folgendes  Beispiel  der  Verknüpfung  zweier  Gleit- 
kommazahlen a  und  b  zeigt: 

log{a  *  b)  =  log(a)  +  log(b) 
log(a/b)  =  log(a)  —  log(b) 

Damit  ist  es  prinzipiell  möglich,  sämtliche  mathematischen  Transformationen  dar- 
auf aufzubauen.  Jedoch  müsste  hierbei  unnötigerweise  zwischen  binärer  und  dezima- 
ler Zahlendarstellung  gewechselt  werden,  was  sich  negativ  auf  die  Programmlaufzeit 
auswirken  würde.  Aus  diesem  Grund  erfand  Konrad  Zuse  im  Jahr  1935  die  Gleit- 
kommazahlendarstellung2. Daraus  entstand  1985  der  IEEE-754-19853  Standard  für 
Gleitpunktarithmetik.  Aus  diesem  ging  eine  überarbeitete  und  erweiterte  Fassung  her- 
vor, der  IEEE-754-2008  Standard  für  Gleitpunktarithmetik.  Dieser  definiert  u.a.  einen 
Standard  für  Dezimalarithmetik  und  Gleitpunktarithmetik  mit  128-Bit  Mantisse.  Es 
wird  das  Buch  von  [Knuth98]  (ab  Seite  214)  empfohlen,  dort  wird  die  Rechnung  mit 
Gleitkommazahlen  und  deren  interne  Darstellung  diskutiert. 


3.1.1    Interne  Darstellung  einer  Gleitkommazahl  nach  IEEE 


[ieee   754]    ieee  Die  Norm  IEEE  754  definiert  die  Darstellung  einer  Gleitkommazahl  x  in  einem  Rech- 

Standard    for    Bina-   ner  wie  fol„t: 
ry  Floating-Point 


Arithmetic  for  mi- 
croprocessor  Systems 
(ANSI/IEEE  Std 
754-1985) 


X 


Gleitkommazahl 


Vorzeichen   Mantisse  BasisExponent 


•  Vorzeichen  s: 

Bei  normalisierten  Gleitkommazahlen  nach  IEEE  754  ist  die  Basis  6  =  2.  Das 
Vorzeichen  s  =  (— l)s  benötigt  ein  Bit  zur  Speicherung.  Ist  S  =  0  ,  so  wird 
eine  positive  Zahl  und  für  S  =  1  eine  negative  Zahl  dargestellt. 

•  Mantisse  rrv. 

Die  Mantisse  m  enthält  die  Ziffern  der  Gleitkommazahl.  Je  mehr  Ziffern  abge- 
speichert werden,  desto  größer  wird  die  Genauigkeit.  Die  Anzahl  p  der  Mantis- 
senbits drückt  also  aus,  wie  exakt  die  Zahl  approximiert  wird.  Dieser  Parameter 
wird  entweder  direkt  oder  in  Form  der  kleinsten  darstellbaren  Zahl  e  fp  angege- 
ben. Diese  Zahl  beschreibt  den  kleinsten  darstellbaren  Wert,  welcher  zur  Zahl  1 
hinzuaddiert  werden  kann  und  ein  von  1  verschiedenes  Ergebnis  liefert4. 

'entnommen  [HuckleOö],  Seite  56 
2siehe  mehr  dazu  http://www.zuse.org 
3siehe  dazu  [IEEE-754-1985] 
4  siehe  [Press92] 
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•  Basis  6: 

Seit  der  Norm  für  Gleitkommazahlen  IEEE  754,  wird  in  den  meisten  Computern 
fast  ausschließlich  die  Basis  6  =  2  verwendet. 

•  Exponent  e: 

Der  Exponent  kennzeichnet  die  Position  des  Kommas  der  Gleitkommazahl.  Da- 
mit ist  auch  die  Größenordnung  der  Gleitkommazahl  festgehalten.  Da  die  An- 
zahl r  der  Exponentenbits  limitiert  ist,  wird  durch  den  Exponenten  der  maxi- 
mal darstellbare  Zahlenbereich  begrenzt.  Die  verfügbaren  Zahlenbereiche  der 
C-Standarddatentypen  sind  aus  der  Tabelle  4.2  ersichtlich. 

3.1.2    Standardrundung  nach  IEEE-754 

Die  Mantisse  einer  normalisierten  Gleitkommazahl  kann  wie  folgt  dargestellt  werden: 

m  =  I.616263.  ..bp-i\bp  (3.1.1) 

Entscheidend  für  die  Rundung  sind  die  Bits  6p_i|6p|6p+i.  Je  nach  Zustand  (0  oder  1) 
wird  entschieden,  ob  auf  -  oder  abgerundet  wird. 


bp-i 

bp 

bp+i 

Aktion 

0  oder  1 

0 

0  oder  1 

abrunden 

0 

1 

0 

abrunden 

1 

1 

0 

aufrunden 

0 

1 

1 

aufrunden 

1 

1 

1 

aufrunden 

Im  Standard  sind  außerdem  noch  drei  weitere  Rundungsverfahren  definiert  (ßoor, 
ceil  und  round  to  zero).  Diese  haben,  verglichen  mit  der  Standardrundung,  einen  grö- 
ßeren Fehler  und  sind  deswegen  für  Standardfälle  nicht  zu  empfehlen.  Eine  Fehlerab- 
schätzung hierfür  ist  in  [HuckleOö]  auf  Seite  64  zu  finden.  Des  Weiteren  werden  die 
Standards  IEEE-754-1985,  IEEE-854-1987  und  IEEE-754-2008  in  [Muller  10]  (Kapi- 
tel 3,  ab  Seite  55)  mit  ihren  speziellen  Eigenschaften  genau  beschrieben. 

3.1.3    Bekannte  Probleme  bei  der  Rechnung  mit  Gleitkommazahlen 

Gleitkommazahlen  werden  verwendet,  um  Zahlen  darzustellen  und  diese  mathemati- 
schen Transformationen  weiter  zu  verarbeiten.  In  diesem  Abschnitt  soll  kritisch  hin- 
terfragt werden,  ob  der  internen  Abbildung  von  Gleitkommazahlen  auf  die  interne 
Struktur  des  Rechners  und  der  darauf  aufbauenden  Verarbeitungsroutinen  blind  ver- 
traut werden  kann.  Des  Weiteren  sollen  einige  Schwachpunkte  aufgezeigt  werden,  um 
den  Blick  für  potentielle  Fehler5  in  Programmen  zu  schärfen. 

Prominente  Beispiele  zu  Fehlerfällen,  welche  durch  falsche  Verwendung  von  Gleit- 
kommazahlen verursacht  wurden,  gibt  es  genügend.  Hier  einige  Auszüge  zu  verschie- 

5  Hierzu  hat  sich  ein  eigener  Forschungszweig  entwickelt  und  es  existieren  bereits  einige  Programme, 
mit  denen  die  Implementierung  von  Gleitkommaoperationen  auf  einer  bestimmten  Hardwareplattform 
überprüft  werden  können.  Hierzu  hat  u.a.  [Verdonk04]  ein  Programm  entwickelt,  welches  die  IEEE-754- 
Kompatibilität  prüft. 
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denen  Disziplinen  der  Wissenschaft: 

•  Due  to  an  error  caused  by  a  homemade  data-analysis  program,  on  page  1875, 
Geojfrey  Chang  and  his  colleagues  retract  three  Science  papers  and  report  that 
two  papers  in  other Journals  also  contain  erroneous  structures.6 

•  ...  was  done  in  by  some  homebrew  Software  which  swapped  two  columns  ofdata. 
In  a  structure  this  large  and  complicated,  you  can  have  such  disruptive  things 
kappen  and  still  be  able  to  settle  down  on  a  final  protein  picture  -  it 's  just  that 
it'll  be  completely  wrong1 

•  ...  have  lead  to  the  determination  and publication  ofincorrect  structures.8 

•  ...An  in  house  data  reduction  program  introduced  a  change  in  signfor  anoma- 
lous differences...We  very  sincerely  regret  the  confusion  that  these  papers  have 
caused  and,  in  particular,  subsequent  research  efforts  that  were  unproductive  as 
a  result  ofour  original  findings.9 

Die  aufgeführten  Beispiele  zeigen,  dass  diese  Probleme  keineswegs  der  Vergan- 
genheit angehören.  Diese  Erkenntnis  zeigt  die  Notwendigkeit  genauer  Betrachtung 
numerisch  berechneter  Ergebnisse  und  deren  darauf  folgende  Interpretation.  Ferner 
muss  sichergestellt  sein,  dass  die  verwendete  Hardwareplattform  korrekte  Ergebnisse 
erzeugt.  Dieses  Misstrauen  ist  gerechtfertigt,  betrachtet  man  die  lange  Liste  der  pro- 
minenten Hardware  -  u.  Software-Fehler  der  letzten  Jahrzehnte: 

•  Bei  der  ersten  Generation  von  Intel  Pentium  Prozessoren  (1987)  trat  bei  der  Di- 
vision bestimmter  Zahlen  ein  Fehler  auf.  Beispielsweise  liefert  die  Berechnung 
des  Bruchs 


8391667/12582905 
anstatt  0.666910...  das  falsche  Ergebnis:  0.666869.... 

[CAS]  •  Das  Computeralgebrasystem  MAPLE10  hatte  mit  der  Version  7.0  Probleme  bei 

Computei-AigebraSystem        der  korrekten  Berechnung  des  Ausdrucks : 

1001! 


1000! 

Dieser  Ausdruck  wurde  fälschlich  zu  1  und  nicht  zu  1001  vereinfacht11. 


•  Mit  der  vorausgegangenen  Version  wurde  eine  lange  Integerzahl  falsch  eingele- 
sen. Die  Zahl 

21474836480413647819643794 


6  siehe  dazu  [Miller06] 

7  siehe  dazu  [Lowe07] 
8siehe  dazu  [Jeffrey07] 
'siehe  dazu  [KavanaghlO] 
'"siehe  dazu  [Maple] 

"Der  Fehlerbericht  zu  diesem  Programmierfehler  kann  unter  folgendem  Weblink  eingesehen  werden: 
http://mathforum.org/kb/message.jspa?messageID=1568841,  Download  am  12.03.2012 


Integerzahlen  werden 
auch  als  Ganzzahlen 
bezeichnet. 
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wurde  durch  einen  Fehler  zu 

413647819643790  +'--.(--.( 

konvertiert. 

Die  aufgeführten  Beispiele  sollen  lediglich  die  Schwächen  heutiger  Softwarerouti- 
nen aufzeigen  und  konsequenterweise  dazu  verleiten,  numerisch  bestimmte  Ergeb- 
nisse sorgfältig  zu  prüfen.  Weitere  Beispiele  dieser  Art  sind  u.a.  in  [MullerlO]  und 
[HuckleOö]  zu  finden. 

Ist  sichergestellt,  dass  die  verwendete  Hardwareplattform  vertrauenswürdige  Ergeb- 
nisse liefert,  so  muss  anhand  entsprechender  Kontrollrechnungen  die  Software  auf  ihre 
Richtigkeit  überprüft  werden.  Dies  erfolgt  in  der  Regel  durch  unit-Tests.  Dabei  werden 
für  jede  der  verwendeten  Funktionen  Testfälle  programmiert,  welche  das  Verhalten  der 
Funktion  aufgrund  unterschiedlicher  Eingabeparameter  überprüfen.  Diese  werden  ge- 
sammelt und  bieten  die  Möglichkeit,  das  gesamte  Programmsystem  oder  auch  nur  ein 
bestimmtes  Modul  durch  den  Aufruf  eines  Befehls  zu  verifizieren.  In  der  industriellen 
Softwareentwicklung  ist  diese  Vorgehensweise  bereits  Standard  und  sollte  ebenfalls  im 
wissenschaftlichen  Bereich  Einzug  halten.  Eine  ausführliche  Beschreibung  zum  Soft- 
waretest mit  unit-Tests  findet  man  in  [Martin09]  (  Kapitel  9,  ab  Seite  159). 
Viele  der  oben  aufgefühlten  Ursachen  hätten  durch  umfangreicheres  Testen  vermieden 
werden  können.  Die  häufigsten  Fehler  können  wie  folgt  kategorisiert  werden:  Division 
durch  Null,  Über-  bzw.  Unterläufe  oder  Fehler,  die  durch  Summierung  von  Rundungs- 
fehlern entstehen. 

Prinzipiell  stellen  Datentypen  für  Gleitkommazahlen  Zahlen  nicht  als  kontinuierliche 
Zahlenfolge  dar,  sondern  als  Exponent,  multipliziert  mit  einer  arithmetischen  Reihe. 
Dies  bedeutet,  es  gibt  eine  untere  und  eine  obere  Schranke  für  die  kleinste  (FLOAT_MIN) 
bzw.  die  größte  darstellbare  Gleitkommazahl  (FLOAT_MAX)  pro  Datentyp.  Durch  das 
Design  der  Gleitkommazahlen-Darstellung  ist  vorgegeben,  dass  zwischen  zwei  aufein- 
ander folgenden  Gleitkommazahlen  eine  Lücke  besteht.  Soll  nun  eine  Zahl  dargestellt 
werden,  die  im  Bereich  der  Lücke  liegt,  so  wird  diese  auf  die  nächst  nähere  Zahl  ge- 
rundet. 


C-Quelltext 

Ausgabe 

floatf=0.1; 

printf(„%.10f",f); 

0.1000000015 

Tabelle  3.2:  Implizites  Runden  durch  Basiswechsel 


Im  C-Quelltext  (siehe  Tabelle  3.2)  wird  die  Zahl  0.1  (Basis  10)  in  die  Binärdarstel- 
lung umgewandelt.  Gerade  diese  Zahl  kann  nicht  auf  die  interne  Darstellung  abgebil- 
det werden,  woraufhin  implizit  gerundet  werden  muss.  Der  dadurch  entstehende  Run- 
dungsfehler kann  durch  Rücktransformation  auf  die  Basis  10  sichtbar  gemacht  werden 
(siehe  rechte  Spalte  von  Tabelle  3.2).  Die  Differenz  zwischen  der  ursprünglichen  Zahl 
mit  dem  Ergebnis  der  Rücktransformation  wird  als  impliziter  Rundungsfehler  bezeich- 
net. Hierbei  sind  zwei  wichtige  Eigenschaften  zu  betrachten: 
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1.  Dieser  Fehler  kann  nicht  vorausberechnet  werden,  da  dieser  von  der  jeweiligen 
Implementierung  abhängig  ist. 

2.  Das  Ergebnis  nach  der  Rücktransformation  kann  entweder  unter  oder  über  dem 
anfänglichen  Wert  liegen,  d.h.  die  Ausgabe  nach  der  Rücktransformation  könnte 
entweder  0.1000000015  oder  auch  0.99999998  lauten. 

Um  dennoch  auf  das  korrekte  Ergebnis  zu  kommen,  kann  ein  Trick  angewandt  werden. 
Dieser  ist  jedoch  nur  möglich,  falls  das  Ergebnis  und  das  Rundungsverhalten  vorher 
bekannt  ist.  Dabei  wird  ein  Korrekturwert  angebracht,  welcher  das  Ergebnis  der  Rück- 
transformation entsprechend  korrigiert.  Das  daraus  errechnete  Ergebnis  stimmt  exakt 
mit  dem  ursprünglichen  Wert  0.1  überein  (siehe  Tabelle  3.3). 


Zeilennummer 

C-Quelltext 

Ausgabe 

1 

floatfiO.l); 

2 

floatflielper(-0. 000000001 5); 

3 

printf( "%.  1 0J\n  ",f+fHelper); 

0.1000000000 

Tabelle  3.3:  Anbringen  einer  Korrektur  zur  Minimierung  des  Rundungsfehlers 


In  der  ersten  Zeile  wird  die  Variable  f  mit  dem  Wert  0  . 1  initialisiert.  Anschließend 
erfolgt  in  der  zweiten  Zeile  die  Initialisierung  einer  Hilfsvariablen  mit  einem  Korrek- 
turwert. In  der  letzten  Zeile  wird  vor  der  Ausgabe  der  Korrekturwert  angebracht  und 
auf  die  Standardausgabe  geschrieben.  Diese  Methode  funktioniert  nur  für  diese  Auf- 
gabenstellung und  diesen  Wert  und  ist  somit  nicht  allgemein  gültig.  Das  Beispiel  soll 
vielmehr  zeigen,  dass  implizites  Runden  fester  Bestandteil  von  Gleitkommazahlen  ist. 
Auch  durch  Vergrößerung  der  Mantisse  kann  dieses  Problem  nicht  behoben  werden, 
sondern  es  wird  lediglich  verlagert.  Abhilfe  hierfür  bietet  die  Rationalarithmetik  bzw. 
die  Dezimalarithmetik.  Ersteres  vermeidet  Gleitkommazahlen,  indem  jede  Zahl  aus 
Zähler  und  Nenner  dargestellt  wird.  Diese  bestehen  aus  ganzen  Zahlen  (Integer)  und 
werden  nicht  gerundet.  Leider  ist  diese  Variante  für  numerische  Integrationsverfahren 
ungeeignet,  da  schon  nach  wenigen  Zeitschritten  ungemein  große  Bruchterme  entste- 
hen, die  nicht  weiter  vereinfacht  werden  können.  Die  Dezimalarithmetik  geht  dabei 
einen  anderen  Weg:  Sie  führt  keinen  Basiswechsel  zwischen  dezimaler  und  binärer 
Darstellung  durch  und  vermeidet  somit  implizites  Runden  bei  der  Initialisierung. 
In  der  Literatur  [HuckleOö]  finden  sich  weitere  prominente  Beispiele  zu  Softwarefeh- 
lern und  die  dadurch  verbundenen  Auswirkungen.  Außerdem  wird  der  Artikel  von 
[MeralilO]  empfohlen.  Darin  befinden  sich  nennenswerte  Statistiken  zu  einer  Umfra- 
ge, bei  der  ca.  2000  Wissenschaftler  aus  unterschiedlichen  Fachgebieten  befragt  wur- 
den. Hier  ein  inhaltlicher  Auszug:  38%  der  Wissenschaftler  verbringen  ein  Fünftel 
ihrer  Arbeitszeit  mit  Softwareentwicklung,  jedoch  haben  nur  47%  davon  das  nötige 
Hintergrundwissen  zum  Softwaretest.  Außerdem  finden  66%  der  Wissenschaftler  eine 
Ausbildung  in  Softwareentwicklung  als  überflüssig.  Ferner  wird  darin  beklagt,  dass 
aufgrund  mangelnder  Dokumentation  die  Wahrscheinlichkeit  für  Folgefehler  enorm 
ansteigt. 
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3.1.4    Antwort  auf  die  Frage:  Warum  werden  nicht  ausschließlich  Gleit- 
kommazahlen verwendet? 

Der  Grund  dafür  liegt  im  Design  der  Gleitkommazahlen  und  dem  daraus  resultierenden 
Fehlerpotential.  Gleitkommazahlen  stellen,  anders  als  Ganzzahlen,  nur  einen  approxi- 
mierten Wert  dar.  Dies  führt  dazu,  dass  das  Assoziativgesetz  ([Bronstein08],  Seite  327, 
Gleichung  5.8a)  bei  Gleitpunktoperation  nicht  gilt.  Folglich  können  die  beiden  Rech- 
nungen ein  unterschiedliches  Ergebnis  erzeugen: 

Für  alle  6!  =  0 


Gleitkommaarithmetik 

Ganzzahlarithmetik 

(a  +  b) +       a  + (b  +  c) 

(a  +  b)  +  c  =  a  +  (6  +  c) 

(a  *b)/b  /  a; 

(a  *  b)/b  =  a 

Aus  diesem  Grund  ist  es  empfehlenswert,  Gleitkommazahlen  nur  dort  einzusetzen,  wo 
es  unbedingt  nötig  ist. 

3.1.5  Rundungsfehleranalyse  (Epsilontik) 

Durch  Analysieren  des  Rundungsfehlers  kann  das  Fehlerverhalten  eines  Verfahrens 
beurteilt  und  die  Größenordnung  des  Fehlers  abgeschätzt  werden.  Dazu  ist  anfänglich 
eine  Begriffsdefinition  nötig,  welche  aus  [HuckleOö]  entnommen  wurde: 

Beispiel  3.1  für  „Realisierung  einer  Gleitkommaoperation" 

Für  jede  Gleitkommaoperation  o  e{+,  — ,  *,  /}  mit  dem  die  Gleitkommazahlen  ai,a2  €  M 
verknüpft  werden,  gilt  folgende  Rechenregel: 

ai  °m  a,2  —  rd{a\  o  a2)  =  (ai  o  a2)(l  +  e0)  (3.1.2) 

wobei  M  die  Menge  aller  Gleitkommazahlen  ist.  Der  relative  Fehler  ist  deshalb  stets  be- 
schränkt durch  |e0|  <  e.  Die  Abschätzung  des  Rundungsfehlers  mit  der  Maschinengenauigkeit 
e  ist  von  zentraler  Bedeutung  und  ermöglicht  nicht  nur  die  Rundungsfehleranalyse  einer  ein- 
zelnen Rechenoperation,  sondern  auch  die  Analyse  der  Fehlerfortpflanzung  durch  eine  Folge 
von  Rechenoperationen. 

Im  Folgenden  soll  die  Analyse  der  Fehlerfortpflanzung  für  den  allgemeinen  Fall 
erarbeitet  werden.  Der  Ausdruck  a\  0  02  bedeute,  dass  zwei  Gleitkommazahlen  mit 
einer  Rechenoperation  ({+,—,*,  /})  verknüpft  werden.  Aus  dieser  Verknüpfung  kann 
konsequenterweise  ein  Rundungsfehler  hervorgehen.  Außerdem  bedeute  die  Verknüp- 
fung ai  o  ü2,  dass  hier  kein  Rundungsfehler  entsteht.  Im  folgenden  Beispiel  soll  ei- 
ne allgemeine  Formel  zu  Abschätzung  des  Rundungsfehlers  erarbeitet  werden.  Diese 
hängt  weder  von  der  Art  der  Verknüpfung,  noch  von  der  Anzahl  der  hintereinander 
ausgeführten  Verknüpfungen  ab. 

3.1.6  Allgemeine  Fehlerfortpflanzung  bei  Gleitkomma- Operationen 

Es  sollen  n  Gleitkommazahlen  ai,...,an  arithmetisch  miteinander  verknüpft  werden, 
wobei  n  €  N  ist.  Die  Verknüpfung  von  n  Gleitkommazahlen  erfordert  n  —  1  arithme- 
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tische  Operationen.  Das  kann  wie  folgt  dargestellt  werden: 

rn-i  =  ai  °  «2  °  •••  °  an  (3.1.3) 

Zur  besseren  Veranschaulichung  der  einzelnen  Verknüpfungen  werde  das  folgende 
Schema  eingeführt,  wobei  mit  für  i  G  N  die  jeweiligen  Zwischenresultate  bezeich- 
net werden: 

ri  =  ai  0  a2 
r2  =  n  0  a3 

r3  =  r20a4  (3.1.4) 


rn-i  =  rn-2  0  a„ 
Nimmt  beispielsweise  n  den  Wert  3  ein,  so  ergibt  sich  folgendes  Schema: 

r\  =  a\  0  a2 

(3.1.5) 

r2  =  n  0  a3 

Aus  der  Erkenntnis  des  vorangegangen  Beispiels  kann  hierfür  der  Rundungsfehler  ent- 
wickelt werden: 

?*2  =  ri  0  a3 

r2  =  (n  o  a3)(l  +  e2) 

r2  =  ((ai0a2)oa3)(l  +  e2)  (3.1.6) 
r2  =        o  ö2)(l  +  ei)  o  o3)(l  +  e2) 

7*2  =  Ol  °  ß2  °  CL3  +  (oi  o  a2)ei  +  (ai  o  a2  o  a3)e2  +  (ai  o  a2)eie2 

Nach  [HuckleOö]  können  die  Terme  höherer  Ordnung  eie2  vernachlässigt  werden,  da 
hierbei  Folgendes  gilt: 

kili  N|  <  e  (3.1.7) 

Somit  sind  Terme  höherer  Ordnung  kleiner  als  e2  und  werden  wegen  e2  «C  e  <C  1 
vernachlässigt.  Hierbei  wird  e  als  Maschinengenauigkeit  bezeichnet.  Somit  kann  der 
erarbeitete  Zusammenhang  ohne  die  Fehlerterme  höherer  Ordnung  vereinfacht  darge- 
stellt werden: 

r2  =  ai  o  a2  o  o3  +  (ai  o  a2)ei  +  (ai  o  a2  o  a3)e2  (3.1.8) 

Aus  dem  Beispiel  für  drei  Verknüpfungen  kann  der  allgemeinere  Zusammenhang  für 
die  Verknüpfung  von  N  Variablen  wie  folgt  dargestellt  werden. 

rn-i  =  ai  o  a2  o  ...  o  an 
+  ei(ai  o  a2) 

+  e2(ai  o  a2  o  a3)  (3.1.9) 
+  ... 

+  e„_i(ai  o  ...  o  an) 


3.1  Gleitkommazahlen 


73 


Dabei  sei  angemerkt,  dass  jeder  der  einzelnen  Fehlerterme  durch  die  vorangegangenen 
Verknüpfungen  beeinflusst  wird.  Im  Folgenden  sollen  für  einige  ausgewählte  Fälle  die 
Formeln  zu  Abschätzung  des  Rundungsfehlers  erarbeitet  werden.  Hierbei  wird  der 
absolute  und  relative  Fehler  als  Gütekriterium  herangezogen. 


Beispiel  3.2  „Rundungsfehleranalyse" 

Es  soll  folgender  Fall  untersucht  werden: 


(a  *  b) 

±  '-  (3.1.10) 


mit  der  Einschränkung  a,b,c  €  N  mit  c  ^  0.  Die  Anzahl  der  Verknüpfungen  ist  zwei,  d.h.  es 
werden  drei  Gleitkommazahlen  miteinander  verknüpft  und  somit  ist  n  =  3.  Daraus  ergibt  sich 
durch  Einsetzen  der  Verknüpfungen  in  Reihenfolge  der  Verarbeitung  (*,  /),  folgender  Term: 

(a  *  b) 

r2  =   

c 

+  e1{a*b)  (3.1.11) 
c 

Der  relative  Fehler,  mit  r*  =       als  Erwartungswert  ist  somit: 


eabs  \r*-r2\ 


|M)-(M)+ei(ab)  +  £2M))| 

(ab) 

—  (3.1.12) 

_  |-(£l(ab)-£2M)| 

(ob) 

c 

=  eic  +  e2 

Hieraus  ist  abzulesen,  dass  t\  ausschließlich  durch  den  numerischen  Wert  der  Variable  c  ver- 
stärkt wird  und  dass  die  numerischen  Werte  der  Variablen  a  und  b  keinen  Einfluss  auf  den 
Rundungsfehler  haben. 

Bei  der  vorausgegangen  Betrachtung  des  Rundungsfehlers  wurde  davon  ausgegan- 
gen, dass  die  Anfangswerte  mit  keinem  Eingangsfehler  behaftet  sind.  Ist  dies  nicht  der 
Fall,  so  müssen  die  jeweiligen  Anfangs  werte  mit  einem  Fehlerterm  (l  +  eai)  mit  i  G  N 
versehen  werden.  Dies  soll  für  n  =  3  demonstriert  werden.  Hierfür  wird  auf  die  bereits 
erarbeitete  allgemeine  Formel  zur  Bestimmung  des  Rundungsfehlers  zurückgegriffen. 
Zunächst  ohne  Eingangsfehler: 


r2  =  a\  o  02  o  ü3 
+  ei(ai  o  a2) 
+  e2(ai  o  a2  o  a3) 


(3.1.13) 


Wird  der  Eingangsfehler  an  jeder  Variablen  angebracht,  kann  der  Ausdruck  wie  folgt 
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erweitert  werden: 


r2  =  ai(l  +  e01)  o  a2(l  +  ea2)  o  a3(l  +  ea3) 

+  ei(ai(l  +  efll)  o  a2(l  +  e„2))  (3.1.14) 
+  £2(ai(l  +  e0l)  o  02(1  +  ea2)  o  03(1  +  e03)) 

Vereinfachung  und  Umsortierung  ergibt: 

r2  =  ai  o  a2  o  a3  +  aieai  +  a2ea2  +  a3ea3 

+  ei(ai  o  a2)  +  ei(aieai  o  a2ea2)  (3.1.15) 
+  e2(ai  o  a2  o  a3)  +  e2(aieai  o  a2ea2  o  a3ea3) 

Werden  analog  zum  vorangegangenen  Vorgehen  die  Terme  höherer  Ordnung  vernach- 
lässigt, so  kann  der  Ausdruck  weiter  vereinfacht  werden  durch: 

r2  =  ai  o  a2  o  a3  +  aieai  +  a2ea2  +  a3ea3 

+  ei(aioa2)  (3.1.16) 
+  e2(ai  o  a2  o  a3) 

Aus  dieser  Darstellung  kann  eine  allgemein  Formel  für  n  Verknüpfungen  abgeleitet 
werden: 

rn_i  =  ai  o  a2  o  ...  o  an 

+  aieai  +  a2efl2  +  ...  +  anean 

+  €\{a\  o  a2) 

^  (3.1.17) 

+  e2(ai  o  a2  o  a3) 

+  ... 

+  e„_i(ai  o  ...  o  an) 

Der  relative  Rundungsfehler  erei  mit  r*  als  Erwartungswert  kann  allgemein  ange- 
geben werden: 

  ^abs 

^rel 

\r*  -r„_i| 


1  , 

-  ~r(ai£ai  +a2£a2  +  •••  +  an£an  (3  118) 

+  ei(a\  o  a2) 

+  e2(ai  o  a2  o  a3) 

+  ... 

+  en_i(ai  o  ...  o  an)) 

Daraus  ist  abzulesen,  dass  der  Eingangsfehler  eai ,  abhängig  vom  Wert  des  Gesamtre- 
sultats, verstärkt  wird.  Die  Eingangsfehler  können  beispielsweise  durch  vorangegan- 
gene Rechnungen  oder  Messfehler  in  die  Rechnung  eingebracht  worden  sein.  Dieser 


3.1  Gleitkommazahlen 


75 


Ausdruck  kann  nun  noch  in  Eingangs  -  u.  Rundungsfehleranteile  aufgeschlüsselt  wer- 
den: 

£rel  =  —  {aiCai  +  02^2  +  •••  +  ön«o„) 
 „  ' 

Eingangs  fehler 

+  e1{aloa2)  {3.1.19) 
+  e2(ai  oa2o  a3) 
+  ... 

+  £n-i(ai  °  •••  °  an)) 
 *  ' 

Rundungs  fehler 

Im  folgenden  Beispiel  soll  der  numerische  Rundungsfehler  für  die  einmalige  Aus- 
wertung der  Duffingschen  Differentialgleichung  abgeschätzt  werden. 

Beispiel  3.3  für  „Rundungsfehleranalyse  der  Duffingschen  Differentialgleichung  (Duffing- 
Oszillator)" 

Der  ungedämpfte  Duffing-Oszillator  ist  eine  nichtlineare  Differentialgleichung  zweiter  Ord- 
nung: 

d!^  =  -uJ2u{t)+8u{tf  (3.1.20) 

mit  den  Konstanten  co,  S  und  u(t)  als  zeitabhängige  Variable.  Im  Folgenden  wird  eine  Run- 
dungsfehleranalyse durchgeführt.  Hierbei  wird  angenommen,  dass  die  Anfangswerte  bereits 
mit  einem  Eingangsfehler  eu^  behaftet  sind.  Ferner  sind  die  verwendeten  Konstanten  u>,  S 
nicht  mit  einem  Eingangsfehler  behaftet.  Um  das  Ergebnis  eines  Aufrufs  der  Kraftfunktion  zu 
ermitteln,  sind  in  diesem  Fall  6  Operationen  nötig  (fünf  Multiplikationen  und  eine  Addition), 
wobei  die  Reihenfolge  genau  eingehalten  werden  muss.  Die  Gesamtanzahl  der  Operationen 
und  deren  Reihenfolge  kann  in  diesem  Fall  direkt  abgelesen  werden: 

d2u(t) 

— p-  =  -uuu(t)  + öu(t)u(t)u(t)  (3.1.21) 

(1)  (2) 

Hierbei  können  Teil  (1)  und  (2)  unabhängig  voneinander  berechnet  werden.  Liegen  die  Teil- 
ergebnisse der  beiden  Teile  vor,  dann  erst  können  diese  addiert  werden.  Für  das  Teilergebnis 
(1)  kann  folgende  Rundungsfehleranalyse  durchgeführt  werden:  In  diesem  Fall  sind  zwei  Mul- 
tiplikationen nacheinander  durchzuführen  und  somit  ist  n  =  2.  Die  Variable  u(t)  ist  mit  einem 
Eingangsfehler  behaftet  und  die  Konstante  oj  nicht.  Dadurch  ergibt  sich  folgende  Darstellung: 

(1)  :=  (w0w)0«(t)(l  +  e„(t)) 

=  ((wou;)(l  +  ei))Ou(t)(l  +  eu(t)) 

=  ((lüuj  +  wwei))u(£)(l  +  e2)(l  +  eu(t))  (3.1.22) 
=  <^i^u{t)u{t)uj2  +  e2euuuj2  +  e1e„(t)Mu;2  +  eu(t)uoj2  +  e^uu:2  +  e2uuj2 
+  eiULO2  +  ulü2 

Hier  werden  Fehlerterme  höherer  Ordnung  vernachlässigt.  Das  ergibt  folgende  vereinfachte 
Formel: 

(1)  :=  u(t)Lü2(eu(t)  +e2  +  e1  +  l)  (3.1.23) 
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Für  das  Teilergebnis  (2)  kann  folgende  Rundungsfehleranalyse  durchgeführt  werden:  In  die- 
sem Fall  sind  drei  Multiplikationen  auszuführen,  wobei  5  nicht  und  u(t)  mit  einem  Eingangs- 
fehler behaftet  ist.  Der  hierbei  verwendete  Rundungsfehlerindex  wird  aus  Teil  (1)  übernom- 
men und  fortgeführt,  d.h.  die  erste  Multiplikation  im  Teil  (2)  erhält  den  Rundungsfehlerindex 
(1  +  e3).  Dieser  Zusammenhang  kann  beschrieben  werden  durch: 

(2)  :=  6  0  u(t)(l  +  eM(t))  0  u(t)(l  +  eu(t))  0  u(t)(l  +  eu(t)) 

=  «Ju(t)(l  +  e3)(l  +  eu{t))u(t)(l  +  e4)(l  +  eu(t))u(t)(l  +  e5)(l  +  eu(t)) 
=  e3  e4  e5  (5  u  (t)3  e^(t)  +  e4  e5  5  u  (t)3  e3(t)  +  e3  e5  5  u  (t)3  e3(t)  +e5k  (t)3  e3(t) 
+  e3  e4  S  u  (i)3  e3(t)  +  e4  ^  u  (t)3  e3(t)  +  e3  5  u  (t)3  e3(t)  +  5  u  (t)3  e3(t) 
+  3  e3  e4  £5  <5  u  (i)3  e2(t)  +  3  e4  e5  5  u  (t)3  e„(t)  +  3  e3  e5  <5  u  (i)3  e„(t)  +  3  e5  5  u  (t)3  e2(t) 
+  3  e3  e4  Ä  u  (t)3  £2(t)  +  3e4öu(t)3  e2u(t)  +  3  e3  6  u  (t)3  e2(t)  +  3  Ä  u  (t)3  e2(t) 
+  3  e3  e4  £5  <5  u  (i)3  eu(t)  +  3  e4  e5  5  u  (t)3  eu(t)  +  3  e3  e5  <5  u  (i)3  eu(t)  +  3e5öu  (t)3  eu(t) 
+  3  e3  e4  £  u  (t)  eu(t)  +  3  e4  <5  u  (t)3  eu(t)  +  3  e3  <5  u  (t)3  eu(t)  +  3  (5  u  (tf  eu(t)  +  e3  e4  e5  5  u  (i)3 

+  e4  e5  <5  u  (i)3  +  £3  e5  <5  u  (t)3  +  e5öu  (t)3  +  e3e4öu  (t)3  +  e4öu  (t)3  +  e3öu  (t)3  +  Su  (tf 

(3.1.24) 

Das  Vernachlässigen  der  höheren  epsilon-Terme  erhält  man  den  Ausdruck: 

(2)  :=  Su(tf(e3  +  e4  +  e5  +  3eu(t)  +  1)  (3.1.25) 
Im  Anschluss  werden  die  Zwischenergebnisse  (1)  und  (2)  noch  addiert: 

cßu(t) 

— ^  =  -(u(t)u2(eu{t)  +€2  +  6!  +  1))  0  5u{t)3(e3  +  e4  +  £5  +  3eu(t)  +  1) 

=  (u(t)uj2(eu{t)  -  c2  -  ei  -  1))  +  <5w(t)3(£3  +  £4  +  £5  +  3eu(t)  +  1)(1  +  e6) 
=  3  e6  5  u  (i)3  eu(t)  +  3  S  u  (i)3  eu(t)  +  uj2  u  (i)  eu(t)  +  e5  e6  (5  u  (t)3  +  e4  e6  <5  u  (tf 
+  e3e6öu(ty  +e6öu(ty  +  e5  S  u  (i)  +  £4  5  u  (i)  +  e3  (5  u  (t)3  +  <5u(t)3 
—  e2  u;2  u  (t)  —  t\  lü2  u  (t)  —  u;2  u  (i) 

(3.1.26) 

Das  Vernachlässigen  der  Terme  mit  höherer  Ordnung  ergibt: 

d2u{t) 


dt2 


=  3e65u(t)  eu(t)+3£u(i)  eu(t)  +  w  u  (i)  eu(t)  +  e5  6 u  (i)  +  e4<Su(i) 
+  e3  S  u  (t)3  -  e2  w2  u  (t)  -  ei  cj2  u  (i)  +  <5  u  (t)3  -  w2  u  (i) 

=  -u?u(t)  +  5u(t)3  -  uj2u(t)(ei  +e2-  eu(t))  +  Su(tf  (e3  +  £4  +  £5  +  3eu(t)  +  3e6  £u(t)) 

S  v-  '      v  v  '      ^  v  ' 

-f  II  III 

Dieser  Ausdruck  kann  in  drei  Hauptanteile  zerlegt  werden.  Der  Teil  I  beschreibt  die  Gleichung 
des  Duffing  Oszillators.  Die  Teile  II  und  III  enthalten  die  Fehleranteile  mit  unterschiedlichen 
Verstärkungsfaktoren.  Teil  II  wird  einfach  durch  den  Wert  von  u(t)  verstärkt,  wohingegen  der 
dritte  Teil  (III)  mit  der  dritten  Potenz  von  u(t)  verstärkt  wird.  Im  Falle  von  5  =  1  und  w  =  1 
muss  zwischen  den  Fällen  unterschieden  werden: 

1.  u(t)  <  1: 

Es  dominiert  der  betragsmäßige  Fehleranteil  II  und  verursacht  somit  den  größten  Run- 
dungsfehleranteil. 
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2.  u(t)  >  1: 

Es  dominiert  der  Term  III  und  liefert  den  größten  Fehleranteil.  Zusätzlich  führt  der 
Eingangsfehler  zu  einer  Verstärkung  um  den  Faktor  3. 

Wie  dieses  Beispiel  gezeigt  hat,  wächst  die  Anzahl  der  Ausdrücke  schon  bei  einfa- 
chen Formeln  sehr  schnell  an.  Das  beschriebene  Vorgehen  zur  Rundungsfehleranalyse 
ist  somit  nur  für  kleine  Ausdrücke  mit  weniger  als  10  Verknüpfungen  geeignet.  Um  für 
umfangreiche  Gleichungssysteme  bzw.  Algorithmen  den  Rundungsfehler  und  dessen 
Verstärkung  formal  zu  erfassen,  wird  der  Einsatz  von  Computeralgebrasystemen  wie 
MATHEMATICA12,  MAXIMA13  oder  Axiom14  empfohlen.  Ferner  kann  auch  Sym- 
bolicC++15  oder  GiNAC16  dafür  verwendet  werden. 

Darüber  hinaus  muss  noch  angemerkt  werden,  dass  die  Rundungsfehleranalyse  für 
Winkelfunktionen  sehr  schwer  durchführbar  ist.  Diese  Funktionen  sind  zwar  Bestand- 
teil der  Programmiersprache,  ihre  interne  Implementierung  ist  jedoch  plattformabhän- 
gig und  unterscheidet  sich  infolgedessen  in  vielen  Fällen  grundlegend  voneinander. 
Um  im  Allgemeinen  die  Analyse  von  Ausdrücken,  basierend  auf  den  vier  Grundre- 
chenarten zu  erleichtern,  ist  Tabelle  3.5  zu  beachten.  Dort  wurde  für  einige  in  der 
Mathematik  häufig  verwendete  Ausdrücke  die  Rundungsfehleranalyse  durchgeführt. 
Dies  soll  als  Ausgangspunkt  für  umfangreichere  Analysen  dienen.  Die  in  Tabelle  3.5 
verwendeten  Variablen  a,  b,  c,  d,  e,  f  sind  nicht  durch  Eingangsfehler  verfälscht. 


Ausdruck 

Rundungsfehler 

a?  ©  b2 

o?  +  b2  +  eia2  +  e2b2  +  e3(a2  +  b2) 

a2  ©  b'2  ©  c2 

a2  +  b2  +  c2  +  aa2  +  e2b2  +  e3(a2  +  b2)  +  e4c2  +  e5(a2  +  b2  +  c2) 

b  ®  d 

g  +  i+eig  +  e2i  +  es(g  +  i) 

b  ®  d  ®  f 

f  +  3  +  f  +^lf  +62§+e3(f  +  §)  +  €4f  +  65(^  +  3  +  f) 

Tabelle  3.5:  Auflistung  häufig  vorkommender  Ausdrücke 


Die  Rundungsfehleranalyse  ist  ein  weites  Feld  und  somit  als  eigene  Disziplin  zu 
betrachten.  Die  hier  aufgeführten  Beispiele  sollen  eine  Hilfestellung  bieten,  um  an 
numerisch  sensiblen  Programmstellen  die  Stabilität  eines  Algorithmus  überprüfen  zu 
können.  Ferner  kann  hiermit  speziell  bei  iterativen  Verfahren  der  entstehende  Run- 
dungsfehler für  jede  Iteration  angegeben  werden  und  dadurch  eine  gute  Fehlerabschät- 
zung durchgeführt  werden.  Außerdem  wird  in  [Jordan72]  (ab  Seite  291)  am  Beispiel 
des  Euler-Cauchy  Integrationsverfahrens  eine  detaillierte  Fehlerabschätzung  durchge- 
führt, welche  auch  den  entstehenden  Rundungsfehler  berücksichtigt.  Ferner  wird  auf 
[Burlisch05]  (ab  Seite  128)  hingewiesen,  wo  der  Einfluss  des  Rundungsfehlers  auf 
Einschrittverfahren  zur  Lösung  gewöhnlicher  Differentialgleichung  abgeschätzt  wird. 
Dort  wird  angemerkt,  dass  der  unvermeidbare  Rundungsfehler  das  Ergebnis  erst  ab 
einer  bestimmten  Integrationsschrittweite  verschlechtert. 

12  siehe  dazu  [Mathematica] 

13  siehe  dazu  [Maxima] 

14  siehe  dazu  [Axiom] 

15  siehe  dazu  [Hardy08] 

16  siehe  dazu  [GiNAC] 
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3.2    Erweiterung  der  Stellengenauigkeit 


Um  mit  höherer  Genauigkeit  als  im  IEEE  754  -  Standard  festgelegt,  rechnen  zu  können 
ist  es  erforderlich,  die  Anzahl  der  Mantissenbits  p  zu  vergrößern.  Um  andererseits  den 
verfügbaren  darstellbaren  Zahlenbereich  zu  erweitern,  muss  die  Zahl  der  Exponenten- 
bits r  inkrementiert  werden.  Dieser  Weg  wurde  bei  den  in  Abschnitt  4  (ab  Seite. 87) 


Exponent 
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m  m 
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m  m 
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nn 


Vorzeichen 

Abbildung  3.1:  Interne  Darstellung  einer  Gleitkommazahl  für  r  =  8  und  p  =  15 


vorgestellten  numerischen  Bibliotheken  beschritten.  Dadurch  ist  es  möglich,  die  Ge- 
nauigkeit von  Rechenoperationen  beliebig  einzustellen.  Die  einzustellende  Genauig- 
keit wird  lediglich  durch  den  limitiert  vorhanden  Speicher  begrenzt. 


3.3    Rechnung  mit  Festpunktzahlen 

Der  Begriff  der  Festpunktzahlen  soll  hier  nur  aus  Gründen  der  Vollständigkeit  erwähnt 
werden.  Diese  Zahlen  besitzen  eine  feste  Anzahl  an  Ziffern,  wobei  die  Position  des  De- 
zimalpunkts festgelegt  ist.  Anders  als  bei  Gleitkommazahlen,  welche  i.d.R.  normali- 
siert dargestellt  werden,  fällt  in  dieser  Darstellungsform  die  Normalisierung  weg.  Auf- 
grund der  festen  Position  des  Dezimalpunkts  können  die  meisten  Operationen  durch 
einfache  Schiebeoperationen  realisiert  werden,  was  in  vielen  Fällen  erhebliche  Vor- 
teile in  der  Abarbeitungsgeschwindigkeit  bringt.  Leider  existieren  aktuell17  keine  frei 
verfügbaren  muitiprecision-Bibliotheken  auf  Festpunktbasis  mit  angemessenem  Funk- 
tionsumfang. 


3.4    Auswahl  einer  geeigneten  Programmiersprache  und  Lauf- 
zeitumgebung 

Für  die  Auswahl  einer  geeigneten  Programmiersprache  ist  es  erforderlich,  die  Aufga- 
benstellung dieser  Arbeit  und  deren  Randbedingungen  genauer  zu  betrachten.  Ziel  ist 
es,  ein  Werkzeug  zur  Lösung  gewöhnlicher  Differentialgleichungen  mit  frei  wählbarer 
Anzahl  signifikanter  Nachkommastellen  zu  schaffen.  Zur  Lösung  gewöhnlicher  Diffe- 
rentialgleichungen existiert  eine  Vielzahl  verschiedener  Algorithmen,  welche  prinzipi- 
ell mit  einer  beliebigen  Programmiersprache  realisiert  werden  könnten.  Die  zusätzli- 
che Anforderung  der  frei  wählbaren  Anzahl  signifikanter  Nachkommastellen  schränkt 
die  Auswahl  möglicher  Programmiersprachen  auf  jene  ein,  die  Datentypen18  zur  ge- 
nauen Rechnung  bereitstellen.  Außerdem  soll  das  hier  geschaffene  Werkzeug  mit  einer 

"Stand  Oktober  2011 

18Datentypen  oder  Bibliotheken  zur  Rechnung  mit  frei  wählbarer  Anzahl  signifikanter  Nachkomma- 
stellen 
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bewährten  und  -  im  Sinne  der  Laufzeit  -  effizienten  Programmiersprache  implemen- 
tiert werden,  um  die  Verbreitung  und  Nachhaltigkeit  des  Werkzeugs  zu  erhöhen.  Als 
Entscheidungshilfe  können  die  Langzeitanalysen19  der  meist  genutzten  Programmier- 
sprachen helfen.  In  Abbildung  3.2  ist  diese  Verteilung  für  den  Zeitraum  von  2002  bis 
2012  aufgetragen20.  Daraus  wird  ersichtlich,  dass  objektorientierte  Sprachen  wie  C++, 


TIOBE  Programming  Community  Index 


□  .□  !■!  I  -  I  ■  m       -         I  I  I  -I-     '  ,  ,  ,— 

2002         2003         2004         2005         2006         2007         2008         2000         2010         2011  2012 

Time 


—  c  —c++ 

—  C# 

(Visual)  Basic 

JavaScript 

—  Java  —  Objective-C 

PHP 

Python 

—  Perl 

Abbildung  3.2:  Langzeitanalyse  des  Anteils  der  zehn  meist  genutzten  Programmier- 
sprachen laut  TIOBE-Index 

Java  oder  Objective-C  weit  verbreitet  sind.  Außerdem  kann  abgelesen  werden,  dass  die 
Sprache  Objective-C  erst  seit  Kurzem  häufig  genutzt  wird.  Auch  prozedurale  Spra- 
chen, wie  beispielsweise  die  Programmiersprache  C,  sind  noch  weit  verbreitet21.  Wird 
alleinig  die  Verteilung  in  Betracht  gezogen,  so  fällt  die  Wahl  der  Programmiersprache 
auf  C++.  Diese  ist  objektorientiert  (siehe  Abschnitt  3.5),  besitzt  die  nötige  Verbreitung, 
um  die  geforderte  Nachhaltigkeit  zu  gewährleisten  und  wird  aktiv  weiterentwickelt22. 
Außerdem  inkludiert  die  Programmiersprache  C++  die  prozedurale  C,  wodurch  sich 
bei  der  Implementierung  auf  dedizierten  Hardwareplattformen23  Vorteile  hinsichtlich 
der  Programmlaufzeit  erzielen  lassen.  Darüber  hinaus  bietet  C++  die  Möglichkeit  der 

"Siehe  mehr  dazu  unter  http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html,  Down- 
load am  11.04.2012 

2CDiese  Grafik  wurde  der  Webseite  http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html 
entnommen  (Download  am  1 1.04.2012). 

21  Große  Projekte  wie  der  Linux-Kernel  oder  der  GNU-Compiler  sind  in  der  Programmiersprache  C 
implementiert. 

22  Informationen  zum  neuen  Sprachstandard  können  auf  der  Webseite  http://www.open- 
std.org/jtcl/sc22/wg21/  (Download  am  11.04.2012)  nachgeschlagen  werden. 

23Siehe  dazu  auch  Abschnitt  5.2. 
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Templateprogrammierung,  mit  der  redundante  Implementierungen  gezielt  vermieden 
werden  können.  Außerdem  hat  die  Sprache  C++,  verglichen  mit  prozeduralen  Spra- 
chen (z.B.  FORTRAN),  einen  syntaktisch  strukturierten  Aufbau.  Dies  ermöglicht  eine 
nachträgliche  Konvertierung  in  andere  objektorientierte  Sprachen  und  ist  somit  zu- 
kunftsweisend. Als  Laufzeitumgebung  wurde  das  freie  Betriebssystem  Linux  gewählt, 
da  es  ohne  eventuell  anfallende  Lizenzgebühren  zur  Verfügung  steht. 


3.5    Konzepte  objektorientierter  Programmierung 

In  den  folgenden  Unterpunkten  wird  kurz  auf  die  grundlegenden  Konzepte  der  objekt- 
orientierten Programmierung  eingegangen.  Darüber  hinaus  werden  die  Paradigmen  der 
Kapselung,  Vererbung,  Operatorüberladung  und  die  C++-Programmierung  mit  Tem- 
plates erklärt. 

3.5.1    Objektorientierte  Programmierung 

Die  Wurzeln  der  Sprache  C++  liegen  in  der  Programmiersprache  C.  C++  ist  syntak- 
tisch und  semantisch  eine  Obermenge  der  Programmiersprache  C.  Die  Programmier- 
[OOP]  Objektorien-  spräche  C++  verfolgt  das  Konzept  der  OOP.  Dadurch  wird  die  Flexibilität  und  die  Wie- 
nerte Programmierung  derverwenclbarkeit  von  Programmen  gefördert.  Das  Grundkonzept  der  OOP  ist,  Daten 
und  Funktionen  möglichst  eng  in  einem  sogenannten  Objekt  zusammenzufassen  und 
nach  außen  hin  zu  kapseln.  Dies  hilft  dedizierte  Zugangspunkte  zu  den  gekapselten 
Daten  zu  schaffen.  Die  jeweiligen  Zugangspunkte  werden  über  Funktionen  realisiert, 
welche  den  Klassen  zugeordnet  sind.  Im  Gegensatz  dazu  beschrieb  das  früher  vor- 
herrschende Programmierparadigma  (prozedurale  Programmierung)  eine  Unterteilung 
zwischen  Funktionen  und  Daten24. 

Begriffsdefinition  DEF3.1  „Klasse  und  Objekt": 

Eine  Klasse  stellt  im  Sinne  der  OOP  eine  Datenstruktur  dar,  welche  Funktionen  und  Daten  in 
sich  vereint.  Diese  Datenstruktur  wird  in  Form  einer  Klassendefinition  festgelegt.  Ein  Objekt 
stellt  eine  konkrete  Realisierung  einer  Klasse  dar.  Mit  Hilfe  der  enthaltenen  Funktionen  kann 
der  Zustand  des  Objekts  auf  eine  definierte  Art  und  Weise  beeinflusst  werden.  Eine  besondere 
Funktion,  die  jede  Klasse  besitzt,  ist  der  Konstruktor.  Dieser  stellt  den  Einsprungspunkt  beim 
Erzeugen  des  Objekts  dar.  Innerhalb  des  Konstruktors  wird  i.d.R.  ein  Objekt  in  einen  definier- 
ten Zustand  versetzt,  in  dem  die  Variablen  der  Klassen  mit  Standardwerten  initialisiert  werden. 

Begriffsdefinition  DEF3.2  „Kapselung": 


Der  Begriff  der  Kapselung  wird  in  der  Programmierung  mit  dem  gezielten  Verbergen  von  Im- 
plementierungsdetails assoziiert.  Der  direkte  Zugriff  auf  die  interne  Datenstruktur  wird  da- 
bei verhindert.  Der  Zugriff  erfolgt  hier  über  eigens  definierte  Schnittstellen.  Laut  Definition 
stellt  ein  Objekt  eine  in  sich  abgeschlossene  Einheit,  ähnlich  einer  black  box  dar.  Von  außen 
betrachtet  stehen  dem  Programmierer  lediglich  die  Schnittstellen  zur  Verfügung,  die  interne 
Darstellung  bzw.  die  Implementierung  bleibt  ihm  dabei  verborgen.  Durch  diese  Abstraktion  ist 
es  möglich,  komplexe  Implementierungsdetails  zu  verbergen.  Dadurch  können  Objekte  als  in 
sich  abgeschlossene  Einheiten  angesehen  werden,  welche  ein  definiertes  Verhalten  besitzen. 


24  siehe  dazu  [Auperle02] 
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DiffEquationT<  T  >  }-Basisklasse 


+  vEquationo  }Schnittstellendefinition 


Loren  z<  T  > 


+  vEquation() 


} abgeleitete  Klasse 

}  Schnittstellen 
Implementierung 


Abbildung  3.3:  Vererbung  von  Schnittstellenfunktionen  an  eine  abgeleitete  Klasse 


Dieses  Konzept  wurde  bei  der  Implementierung  der  Software  zur  numerischen 
Integration  eingesetzt.  Dabei  wurde  jedes  der  implementierten  Verfahren  in  eine  eigene 
Klasse  gekapselt.  Somit  besitzt  die  Klasse  ausschließlich  definierte  Schnittstellen  und 
die  interne  Funktionalität  ist  von  außen  nicht  einsehbar. 

Begriffsdefinition  DEF3.3  „Vererbungsprinzip": 

Das  Konzept  der  Vererbung  ermöglicht  die  Wiederverwendung  vorhandener  Klassendefinitio- 
nen. Hieraus  können  wieder  neue  Klassen  definiert  werden,  indem  deren  Funktionalität  vererbt 
und  verfeinert  wird.  Dadurch  ist  es  beispielsweise  möglich,  die  Funktionalität  einer  Basisklas- 
se in  die  eigene  Klassendefinition  mit  aufzunehmen  und  einige  zusätzliche  Aspekte  hinzuzu- 
fügen, ohne  die  Basisklasse  zu  verändern.  Die  Vererbung  kann  somit  auch  als  eine  Art  der 
Spezialisierung  angesehen  werden. 

Dieses  Konzept  wurde  beispielsweise  bei  der  Definition  einer  Klasse  eingesetzt, 
welche  die  Implementierung  einer  Differentialgleichung  enthält.  Dabei  wurde  erst  ei- 
ne Basisklasse  definiert,  welche  die  nötigen  Schnittstellenfunktionen  zum  Aufruf  der 
rechten  Seite  einer  Differentialgleichung  enthalten  soll.  Diese  Klasse  besitzt  zunächst 
noch  keine  konkrete  Differentialgleichung,  sondern  definiert  lediglich  die  Schnittstel- 
lenfunktion in  allgemeiner  Form.  Konkretisiert  wird  dieses  Konzept  erst,  wenn  eine 
Klasse  von  dieser  Basisklasse  abgeleitet  wird  und  damit  die  Schnittstellen  der  Basis- 
klasse erbt.  Folglich  wird  auch  die  Gestalt  der  Funktionsdefinition,  die  zum  Aufruf  der 
entsprechenden  Funktion  nötig  ist,  auf  die  abgeleitete  Klasse  übertragen.  Durch  Über- 
schreiben dieser  speziellen  Schnittstellenfunktion  innerhalb  der  abgeleiteten  Klasse 
erfolgt  eine  Spezialisierung,  d.h.  es  wird  eine  konkrete  Differentialgleichung  hinter- 
legt, wie  z.B.  die  Differentialgleichung  des  Lorenz- Attraktors.  Dies  hat  den  Vorteil, 
dass  alle  Algorithmen  zur  Lösung  von  Differentialgleichungen  lediglich  die  Schnitt- 
stelle der  Basisklasse  kennen  und  dadurch  eine  Trennung  zwischen  konkreter  Aufga- 
benstellung (z.B.  Differentialgleichung)  und  numerischem  Lösungsverfahren  gewahrt 
bleibt.  In  Abbildung  3.3  wird  anhand  eines  konkreten  Beispiels  die  Ableitungsbezie- 
hung in  UML25  konformer  Notation  dargestellt.  Darin  leitet  die  Klasse  Lorenz  von  der  [uml]  Unified 
Klasse  DiffEquationT  ab.  Diese  wird  somit  zur  Basisklasse  der  Klasse  Lorenz,  welche  M°deiimg  Language 
die  Schnittstellendefinition  erbt.  Durch  einfaches  Implementieren  (Hinterlegen  einer 
konkreten  Differentialgleichung)  innerhalb  der  Klasse  Lorenz  wird  eine  standardisier- 
te Schnittstellenkonvention  aufrecht  erhalten.  In  Listing  3.1  ist  dieser  Zusammenhang 
als  C+-r-Quelltext  ausgedrückt.  Dies  ist  eine  reduzierte  Form  der  konkreten  Imple- 


siehe  dazu  [ErlerOO] 
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mentierung  und  soll  lediglich  das  Prinzip  der  Vererbung  in  den  Vordergrund  rücken, 
da  ein  Großteil  der  hier  entwickelten  Software  auf  diesem  Prinzip  aufbaut.  In  Zeile 
4  wird  die  Funktion  vEquation  definiert,  jedoch  nicht  implementiert,  und  in  Zeile  9 
erfolgt  die  Implementierung.  An  dieser  Stelle  wird  die  jeweilige  Differentialgleichung 
definiert. 

1  template  <typename  T>  class   Dif fEquationT 

2  ! 

3  public  : 

4  Virtual   void   vEquation  ()   =  0; 

5  }; 

6  template  <typename  T>  class  Lorenz   :   public  DiffEquationT  <T> 

7  ! 

8  public  : 

9  void   vEquation  (){  J 
10  }; 

Listing  3.1:  Quell textauszug  zur  Vererbung  von  Schnittstellenfunktionen 

Noch  hat  dieses  Prinzip  keinen  Vorteil,  da  eine  konkrete  Anwendung  für  die  standardi- 
sierte Schnittstelle  fehlt.  Zur  Lösung  von  Differentialgleichungen  werden  Integratoren 
verwendet,  welche  genau  diese  Standardschnittstelle  benötigen.  Es  ist  außerdem  vor- 
teilhaft diese  Algorithmen  nur  einmal  zu  implementieren  und  die  jeweilige  Aufgaben- 
stellung (Differentialgleichung)  dem  Verfahren  zu  einem  späteren  Zeitpunkt  mitzutei- 
len. In  Listing  3.2  ist  ein  Beispiel  abgebildet,  worin  die  Verwendung  einer  abstrak- 
ten Schnittstellendefinition  vorteilhaft  ist.  Darin  ist  eine  Klasse  IntegratorT  definiert. 
Diese  besitzt  einen  Memberpointer  vom  Typ  der  abstrakten  Basisklasse  DiffEquati- 
onT. Diese  wird  während  des  Aufrufs  im  Konstruktor  initialisiert  (Zeile  5).  In  Zeile 
21  wird  nun  ein  Objekt  einer  konkrete  Differentialgleichung  erzeugt  und  in  Zeile  22 
dem  Konstruktor  der  Klasse  IntegratorT  übergeben.  Schließlich  kann  in  der  Funkti- 
on vStep  in  der  Klasse  IntegratorT  die  Funktion  vEquation  aufgerufen  werden  (siehe 
Zeile  1 1  und  23).  Somit  ist  die  Implementierung  des  Algorithmus  und  die  Implemen- 
tierung der  konkreten  Aufgabenstellung  getrennt  und  kann  nach  Bedarf  miteinander 
verknüpft  werden. 

1  template  <typename  T>  class  IntegratorT 

2  ! 


3  public  : 

4  explicit    IntegratorT  (  DiffEquationT  <T>  *  Dif f EquationPtr  ) 

5  :  m_pDiffEquation  (DiffEquationPtr) 

6  I 

7  } 
8 

9  void  vStep() 

10  { 

11  m_pDiffEquation  — >vEquation  ()  ; 

12  } 
13 

14  private : 

15 

16  DiffEquationT  <T>  *  m_pDiffEquation  ; 


17  }; 
18 

19  int  main() 
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20  { 

21  Lorenz  <double  >  LorenzEquation  ; 

22  IntegratorT  <double  >  In  t e gr at or  (&LorenzEquation  )  ; 

23  Integrator . vStep () ; 

24  return  0; 

25  } 

Listing  3.2:  Quelltextauszug  zur  Nutzung  von  Schnittsteilendefinitionen 
Begriffsdefinition  DEF3.4  „Operatorüberladung": 

Die  Operatorüberladung  ist  ein  überaus  nützliches  Werkzeug  der  OOP.  Damit  ist  es  beispiels- 
weise möglich,  die  Rechenoperatoren  wie  +,—,*,/  mit  neuen  Funktionen  auszustatten  bzw. 
diese  Operanden  für  bestimmte  Zwecke  neu  zu  definieren.  Für  alle  primitiven  Standardda- 
tentypen sind  diese  Überladungen  bereits  vorhanden.  Dadurch  wird  die  Addition  von  allen 
primitiven  numerischen  Datentypen  ermöglicht.  Das  Konzept  erlaubt  es,  die  für  jede  Klasse 
notwendigen  Operatoren  zu  überladen. 

Das  Prinzip  der  Operatorüberladung  wurde  in  dieser  Arbeit  massiv  eingesetzt.  Bei- 
spielweise wurde  eine  Klasse  (VectorT)  zur  Speicherung  von  Daten  in  Form  eines 
Vektors  definiert  und  dort  alle  nötige  Operatoren  überladen. 

Begriffsdefinition  DEF3.5  „Templateprogrammierung": 

Das  Konzept  der  Templates  ermöglicht  es,  eine  vom  Datentyp  unabhängige  Programmierung 
zu  realisieren.  Dabei  wird  der  verwendete  Datentyp  variabel  definiert.  Wird  dieses  Konzept 
durchgehend  umgesetzt,  dann  ist  zur  Implementierung  eines  bestimmten  Algorithmus  nur  ei- 
ne einzige  Templateklasse  nötig.  Diese  besondere  Art  der  Unabhängigkeit  vom  verwendeten 
Datentyp  fördert  die  Wiederverwendbarkeit  im  Sinne  der  Softwareentwicklung. 

Alle  Funktions-  und  Klassendefinition,  welche  im  Rahmen  dieser  Arbeit  entwickelt 
wurden,  sind  als  Templates  realisiert.  Ansonsten  hätte  jedes  der  Lösungsverfahren  ei- 
ne eigene,  auf  den  verwendeten  Datentyp  zugeschnittene  Implementierung  bekommen 
müssen.  Folglich  braucht  nur  ein  Quelltext  gepflegt  zu  werden  und  es  werden  Mehr- 
deutigkeiten unterschiedlicher  Realisierungen  eines  bestimmten  Verfahrens  implizit 
ausgeschlossen.  Im  Allgemeinen  wird  eine  Templatefunktion  in  der  Programmierspra- 
che C++  wie  folgt  formuliert. 

1  template  <typename  T>  void  Funktionsname  (  Parameter ) 

2  {Funktionsrumpf} 

Listing  3.3:  Definition  einer  Templatefunktion 

Durch  die  syntaktische  Deklaration  template  <typename  T>  wird  der  Datentyp 
durch  den  Schablonenparameter  T  eingeführt.  Dieser  kann  im  Funktionsrumpf  wie  ein 
herkömmlicher  Datentyp  verwendet  werden.  Die  Aufrufe  dieser  Templatefunktion  für 
die  Datentypen  bigßoat  und  double  lauten  dann  wie  folgt: 

1  Funktionsname <bigfl o at  >()  ; 

2  Funktionsname <double  >()  ; 


Listing  3.4:  Instanziierung  einer  Templatefunktion 
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Wird  dieser  Quelltext  übersetzt,  so  erfolgt  in  der  Präprozessierungsphase  des  Compi- 
lers eine  Instanziierung  der  Templates,  d.h.  erst  zu  diesem  Zeitpunkt  wird  aus  einer 
Templatefunktion  eine  herkömmliche  Klasse  im  Sinne  der  OOP. 

3.5.2    Vektor  -  und  Matrixoperationen 

Zur  Rechnung  mit  Vektoren  und  Matrizen  wurden  die  Klassen  VectorT  und  MatrixT 
als  Templateklassen  implementiert.  Durch  die  bereits  vorgestellte  Operatorüberladung 
enthalten  diese  Klassen  einen  Großteil  der  Grundoperationen,  welche  zur  Rechnung 
mit  Matrizen  und  Vektoren  erforderlich  sind. 


3.6    Objektorientierte  Implementierung  der  Integrations ver- 
fahren 

Die  verschiedenen  Algorithmen  zur  Lösung  gewöhnlicher  Differentialgleichungen  wur- 
den jeweils  in  eine  eigene  Klasse  gekapselt.  Aus  der  Sicht  eines  Anwenders  sind  die 
unterschiedlichen  Integratoren  Werkzeuge  zur  Lösung  gewöhnlicher  Differentialglei- 
chungen. Somit  soll  jeder  der  Algorithmen  möglichst  ohne  Abhängigkeiten  einsetzbar 
sein.  Dies  wird  zunächst  realisiert,  indem  jedes  der  implementierten  Lösungsverfahren 
von  einer  Basisklasse  (  hier  IntegratorBaseT)  ableitet.  Infolgedessen  erzwingt  dies  ei- 
ne Standardisierung  der  Schnittstelle  eines  Integrationsverfahrens  im  Allgemeinen.  In 
Abb.  3.4  ist  dieser  Zusammenhang  exemplarisch  dargestellt.  Besonderes  Augenmerk 


IntegratorßaseK  T  > 


Schnittstellendefinition 


+  IntegratorBaseTÜ 
+  -IntpQratorRasp.TO 


+  StepO 


T 


Implementierung 


RK4T<  T  > 


■  n_eqn 

■  m  DiffEqu 

■  ><_1 

■  >e_2 

■  k  3 

■  ><_4 

■  templ 

■  tl 

■  t2 


+  RK4T0 
+  RK4T0 
+  -RK4TÜ 


+  5t*  : 


+  RK4T0 
+  operator={) 


DiffEquationT<  T  > 


+  vEquation() 


Abbildung  3.4:  Klassendiagramm  der  Klasse  RK4  (Runge-Kutta  4.0rdnung) 


soll  hier  auf  die  Funktion  vStep  gelegt  werden.  Deren  Schnittstelle  wird  in  der  Basis- 
klasse IntegratorBaseT  definiert  und  in  der  abgeleiteten  Klasse  RK4T  implementiert. 


3.6  Objektorientierte  Implementierung  der  Integrationsverfahren 
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Außerdem  besitzt  die  Klasse  RK4T  eine  Zeigervariable  der  abstrakten  Basisklasse 
DiffEquationT.  Diese  wird  benötigt,  um  eine  bestimmte  Aufgabenstellung  (Differen- 
tialgleichungen) zu  lösen  (siehe  mehr  dazu  im  Abschnitt  3.5.1).  Im  Folgenden  soll  die 
Verwendung  dieses  Verfahrens  in  einem  kurzen  Quell textauszug  gezeigt  werden: 


1 

//   de f ine  datatype 

2 

typedef  double  T; 

3 

//   create    local  variables 

4 

T  Starttime  =0.0  ,  Stepsize  =0. 1 ; 

5 

//    create   an   vector    of  dimension 

=  2 

6 

VectorT<T>  S  t art Vec t or  ( 2 )  ; 

7 

StartVector  [0]  =  1; 

8 

StartVector  [1]  =  0; 

9 

//    create   a   D  iffE  quation  object 

10 

DuffingT<T>  Duffing  ; 

11 

//   create  a  Runge— Kutta  object 

12 

RK4T<T>  RK4(&Duffing  ,  StartVector 

.  size  ()  )  ; 

13 

//  perform   one    Integration  Step 

14 

RK4.  vStep  (  Starttime  ,  StartVector, 

Stepsize ) ; 

Listing  3.5:  Quelltextauszug  zur  Verwendung  eines  speziellen  Integrationsverfahrens 


In  Listing  3.5  wird  erst  eine  Verallgemeinerung  des  verwendeten  Datentyps  (hier  dou- 
ble, Zeile  2)  vorgenommen.  Anschließend  wird  die  Startzeit  und  die  Schrittweite  defi- 
niert (Zeile  4).  In  Zeile  6  wird  ein  VectorT-Objekt  erzeugt  und  in  den  darauf  folgen- 
den Zeilen  werden  die  Anfangswerte  zur  Integration  gespeichert.  Des  Weiteren  wird 
in  Zeile  10  ein  Objekt  der  DufüngT -Klasse,  angelegt.  Darin  ist  die  Differentialglei- 
chung des  ungedämpften  Duffing-Oszillators  hinterlegt.  Anschließend  wird  in  Zeile 
12  eine  Instanz  des  Runge-Kutta-Integrationsverfahrens  erzeugt.  Der  Konstruktor  der 
RK4T-Klasse  verlangt  einen  Zeiger  auf  ein  Objekt  vom  Typ  DiffEquationT  und  die 
Dimension  des  Startvektors  in  der  Parameterliste.  Schließlich  wird  ein  Integrations- 
schritt durchgeführt,  indem  die  Funktion  vStep  aufgerufen  wird.  Nach  dem  Aufruf 
enthält  der  Startvector  die  Werte  zum  Zeitpunkt  tstart  +  h,  wobei  h  ein  Platzhalter  für 
die  Schrittweite  ist. 

3.6.1    Kapselung  der  Integrationsverfahren  in  der  Klasse  IntegratorT 

Im  Abschnitt  3.6  wurde  auf  die  objektorientierte  Implementierung  eines  speziellen 
Integrationsverfahrens  verwiesen.  Da  im  Rahmen  dieser  Arbeit  unterschiedliche  Inte- 
grationsverfahren umgesetzt  wurden,  ist  es  nötig,  diese  in  einer  Klasse  (IntegratorT) 
zusammenzufassen.  Die  hierzu  verwendeten  Vererbungsbeziehungen  sind  in  Abb.  3.5 
dargestellt.  Im  Sinne  der  Softwareentwicklung  wurde  an  dieser  Stellte  das  Fassade- 
Entwurfsmuster26  umgesetzt.  Im  Allgemeinen  bietet  es  eine  einheitliche  Schnittstelle 
zu  einem  Subsystem  verschiedener  Klassen.  In  diesem  Fall  wird  ein 

kt  zu  den  jeweils  implementierten  Integrationsverfahren  geschaffen.  Wird  die  Inte- 
gratorT'-Klasse  verwendet,  so  kann  das  verwendete  Lösungsverfahren  lediglich  durch 
Abwandlung  eines  Attributes  geändert  werden,  was  die  Implementierung  erleichtert. 
Dies  soll  durch  Listing  3.6  veranschaulicht  werden.  In  den  Zeilen  eins  bis  zehn  wer- 
den analog  zum  vorangegangenen  Beispiel  die  Startwerte  initialisiert  und  ein  Objekt 

26Mehr  Informationen  zu  diesem  und  anderen  Entwurfsmustern  der  Softwareentwicklung  findet  man 
bei  [GammaOl]. 
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Kapitel  3:  Implementierungs aspekte 


r 


Schnittstellendefinition 


r 


Implementierung  < 


lntegrator8aseT<  T  > 


+  IntegratorBaseTO 
+  -IntegratorBaseTl) 
+  vStep() 


IntegratorK  T  > 


■  m_pDiffEquation 
•  m_plntegratorType 


+  IntegratorK) 
+  vStepd 


Zentraler 
Zugangspunkt 


RK10T<  T  > 


■  m_pDiffEquation 


+  RK10T0 
+  vStepO 


RK4T<  T  > 


•  m_pDiffEquation 


+  RK4T0 
+  vStep() 


Verschiedene 
Lösungsverfahren 


DiffEquationT<  T  > 


+  vEquation() 


Lorenz<  T  > 


+  vEquation() 


Differentialgleichung 


Abbildung  3.5:  IntegratorT  als  zentraler  Zugangspunkt  zur  Integration  von  Differenti- 
algleichungen 


zur  Lösung  einer  gewöhnlichen  Differentialgleichung  angelegt.  In  Zeile  zwölf  wird 
ein  Objekt  vom  Type  IntegratorT  erzeugt.  Zur  Erzeugung  eines  IntegratorT-Objekts 
werden  identische  Parameter,  analog  zu  den  Integrationsverfahren,  benötigt.  Darauf- 
hin wird  in  Zeile  14  das  zur  Berechnung  verwendete  Integrations verfahren  festgelegt. 
In  diesem  Fall  wird  das  Runge-Kutta- Verfahren  (4.  Ordnung)  ausgewählt.  Anschlie- 
ßend wird  in  Zeile  16  ein  Integrationsschritt  durchgeführt.  Um  das  Umschalten  zwi- 
schen den  verschiedenen  Lösungs verfahren  zu  demonstrieren,  wird  in  Zeile  18  auf  das 
Runge-Kutta- Verfahren  (10.  Ordnung)  umgeschaltet. 

1  //   de f ine  datatype 

2  typedef  double  T; 

3  //   create    local  variables 

4  T  Starttime  =0.0  ,  Stepsize  =0. 1 ; 

5  //    create   an    vector    of  dimension  =  2 

6  VectorT<T>  S  t art V ec t or  ( 2 )  ; 

7  StartVector  [0]  =  1; 

8  StartVector  [1]  =  0; 

9  //    create   a   D  iffE  quation  object 

10  LorenzT<T>  Lorenz  ; 

11  //   create   an   IntegratorT  object 

12  IntegratorT  <T>  Integrator(&Lorenz  ,    S t art V ec t or  .  s i ze  ( )  )  ; 

13  //    set    Integrator  type 

14  Integrator.  vSetlntegratorType  (RK4)  ; 

15  //  perform   one    Integration  Step 

16  Integrator.  vStep(  Starttime,    StartVector,  Stepsize); 

17  //   change    Integrator    type    to  RK10 

18  Integrator.  vSetlntegratorType  (RK10)  ; 

Listing  3.6:  Quelltextauszug  zur  Verwendung  der  Integrator T-Klasse 


Kapitel  4 

Eignung  von  multiprecision -Bibliotheken 


Schwerpunkt  des  Kapitels: 

Aufgrund  der  Vielzahl  frei  verfügbarer  multiprecision-Bibliotheken  für  die  Program- 
miersprache C/C++,  ist  es  nötig,  eine  Evaluierung  hinsichtlich  funktionaler  Ausstat- 
tung und  deren  Laufzeitverhalten  durchzuführen.  Folgende  Bibliotheken  wurden  un- 
tersucht: 

•  LiDIA 

•  NTL 

•  CLN 

•  MAPM 

•  GMP 


87 


88 


Kapitel  4:  Eignung  von  muitiprecisiori-BiBLiOTHEKEN 


4.1    Auswahl  einer  geeigneten  multiprecision -Bibliothek 

Neben  kryptographischen1  und  zahlentheoretischen  Anwendungen  ist  die  Rechnung 
mit  höherer  Anzahl  signifikanter  Nachkommastellen  für  die  Lösung  von  Bewegungs- 
problemen ein  außerordentlich  wertvolles  Hilfsmittel.  Damit  ist  es  möglich,  die  gerade 
verwendeten  Algorithmen  auf  ihre  numerische  Stabilität  und  Robustheit  zu  testen.  Soll 
eine  Simulation  mit  höherer  Genauigkeit  durchgeführt  werden,  so  dauert  dies,  vergli- 
chen mit  herkömmlich  verfügbarer  Genauigkeit,  in  der  Regel  länger.  Ein  Grund  dafür 
ist,  dass  die  Berechnung  einer  Zahl  mit  höherer  Genauigkeit  in  Software  abgebildet 
werden  muss,  ganz  im  Gegensatz  zu  den  Basisdatentypen,  welche  i.d.R.  direkt  auf 
[CPU]  Centrai  der  CPU  verarbeitet  werden.  Aus  diesem  Grund  ist  es  entscheidend  zu  wissen,  wel- 
Processing  Unit  ^  zahireich  verfügbaren  Bibliotheken  zur  Rechnung  mit  frei  wählbaren  Stellen- 

genauigkeiten für  die  aktuelle  Aufgabenstellung  am  geeignetsten  ist.  Zudem  gibt  es, 
allein  für  die  Programmiersprachen  C/C++,  eine  Vielzahl  verschiedener  open-source- 
Bibliotheken.  Eine  kurze  Übersicht  zu  einigen  aktuell2  verfügbaren  Bibliotheken,  ka- 
tegorisiert  nach  den  jeweils  mitgelieferten  Datentypen,  ist  in  Tabelle  4.1  angegeben3. 


Name 

Version 

Integer 

Float 

Decimal 

Complex 

Rational 

LiDIA 

2.3.0 

/ 

/ 

/ 

/ 

NTL 

5.5.2 

/ 

/ 

CLN 

1.3.2 

/ 

/ 

/ 

/ 

GMP 

5.0.2 

/ 

/ 

/ 

ttmath 

0.9.2 

/ 

/ 

MAPM 

4.9.5a 

/ 

/ 

Tabelle  4.1:  Übersicht  zu  multiprecision -Bibliotheken  für  die  Programmiersprache 
C++ 

Prinzipiell  können  die  jeweiligen  Auswahlkriterien  in  zwei  Hauptkategorien  ein- 
geteilt werden: 

•  Funktionsumfang 

Der  unterstützte  Funktionsumfang,  hinsichtlich  mathematischer  Transformatio- 
nen, ist  eines  der  wichtigsten  Kriterien  bei  der  Bewertung  von  multiprecision- 
Bibliotheken.  Ohne  diesen  grundlegenden  Funktionsumfang  ist  die  Bibliothek 
bzw.  der  jeweilig  enthaltene  multiprecision -Datentyp  nur  begrenzt  nutzbar. 

•  Abarbeitungsgeschwindigkeit 

Als  ebenfalls  wichtiges  Kriterium  kann  die  Abarbeitungsgeschwindigkeit  ange- 
sehen werden.  Diese  kann  sich,  abhängig  von  der  untersuchten  Problemstellung 
und  Hardwareplattform,  unterschiedlich  verhalten.  Somit  kann  keine  pauschale 
Antwort  gegeben  werden,  welcher  Datentyp  die  beste  Abarbeitungsgeschwin- 
digkeit besitzt.  Dennoch  können  synthetische  Leistungsmessungen  (Benchmarks) 

1  siehe  mehr  dazu  unter  [DenisOö] 
2November2011 

3Es  gibt  noch  weitere  Bibliotheken  mit  ähnlicher  Ausstattung  an  Datentypen.  Diese  werden  hier  be- 
wusst  nicht  erwähnt,  da  eine  vollständige  Gegenüberstellung  den  Rahmen  dieser  Arbeit  sprengen  würde. 


4.3  ÜBERSICHT  ZU  DEN  VERWENDETEN  muitipretisiofi-BlBLIOTHEKEN 
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eine  gute  Hilfestellung  bei  der  Auswahl  bieten.  Die  letztendlich  erzielte  Abar- 
beitungsgeschwindigkeit kann  weiter  nach  Einflußgrößen  aus  Hard  -  und  Soft- 
ware kategorisiert  werden: 

-  Hardware: 

*  Welche  Hardwarearchitektur  liegt  zu  Grunde  (32/64-Bit  CPU)? 

*  Mit  welcher  Frequenz  ist  die  CPU  getaktet? 

*  Wie  viele  Rechenkerne  besitzt  die  CPU? 

*  Welche  Menge  RAM  steht  auf  der  Zielplattform  zur  Verfügung? 

-  Software: 

*  Wurde  der  Test  auf  einem  Echtzeitbetriebssystem  durchgeführt? 

*  Welcher  Compiler  wurde  zum  Übersetzen  der  Anwendung  verwen 
det? 

*  Welche  Optimierungen  wurden  durch  den  Compiler  vorgenommen? 

*  Wurde  der  Quellcode  handoptimiert,  evtl.  durch  inline  -Assembler? 

*  Welche  arithmetische  Operation  wird  am  häufigsten  ausgeführt? 

4.2    Standardmäßig  verfügbare  dezimale  Genauigkeit 

Der  IEEE  754-1985  Standard  für  Gleitkommaarithmetik  definiert  zwei  Formate  zur 
Darstellung  von  Gleitkommazahlen.  Diese  besitzen  jeweils  eine  fest  vorgegebene  An- 
zahl an  verwendeten  signifikanten  Nachkommastellen.  Diese  sind  Bestandteil  der  Pro- 
grammiersprache C/C++  und  werden  als  ßoat  und  doubie-Datentypen  bezeichnet.  Die 
Tabelle  4.2  zeigt  eine  Übersicht  der  Basisdatentypen  mit  deren  dezimalen  Stellenge- 
nauigkeiten, Wertebereichen,  Größen  und  Mantissenlänge4.  Weiter  ist  dort  auch  der 
long  double-Datentyp  aufgelistet.  Dieser  wird  nicht  im  IEEE-Standard  definiert,  wird 
aber  aus  Gründen  der  Vollständigkeit  dennoch  in  die  Vergleiche  miteinbezogen. 


Bezeichnung 

Größe 

Dezimale  Genauigkeit 

Mantissenlänge 

float 

4  Byte 

6-stellig 

23  Bit 

double 

8  Byte 

15-stellig 

53  Bit 

long  double 

10  Byte 

19- stellig 

80  Bit 

Tabelle  4.2:  Übersicht  der  Wertebereiche  und  Stellengenauigkeiten  der  Standarddaten- 
typen 


4.3    Übersicht  zu  den  verwendeten  multiprecision -Bibliotheken 

In  Folgendem  werden  die  verwendeten  multiprecision -Bibliotheken  kurz  vorgestellt. 


4vgl.  dazu  [Wolf06] 


[CPU]Central 
Processing  Unit 


[RAM]  Random 
Access  Memory 


90 
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4.3.1    Die  LiDIA  -  Bibliothek 

Die  LiDIA-Bibliothek5  wurde  an  der  Technische  Universität  Darmstadt6  entwickelt. 
Ein  Großteil  der  in  der  C-Standardbibliothek  enthaltenen  arithmetischen  Grundope- 
rationen ist  in  der  LiDIA-Bibliothek  auf  Basis  von  Gleitpunktdatentypen  implemen- 
tiert. Zur  Untersuchung  wurde  die  aktuellste  Version  der  LiDIA-Bibliothek  verwendet 

[GMP]  gnu  Multi-  (stand  18.05.2007,  Version  2.2.O.).  Die  LiDIA-Bibliothek  verwendet  intern  die  GMP7. 

precision  Library  Außerdem  konnten  in  Zusammenarbeit  mit  den  Autoren  der  LiDIA-Bibliothek  eine 
Reihe  von  Programmierfehlern  beseitigt  werden8. 


4.3.2    Die  NTL  -  Bibliothek 

[NTL]  Number  Theo- 
rie Library  Die  NTL  _  Bibliothek9  wurde  von  Victor  Shoup10  an  New  York  University11  ent- 
wickelt. Sie  ist  eine  hoch  optimierte  numerische  Bibliothek,  die  einen  ähnlich  hohen 
Funktionsumfang  aufweist,  wie  die  LiDIA  -  Bibliothek.  Sie  bietet  Datentypen  für  Fest 
-  und  Gleitkommaarithmetik  mit  einstellbarer  Stellengenauigkeit.  Darüber  hinaus  sind 
auch  Vektor  und  Matrixoperationen  enthalten.  Jedoch  ist  die  Auswahl  an  trigonometri- 
schen Funktionen  geringer  (s.  4.4.2).  Zur  Untersuchung  wurde  die  aktuellste  Version 
der  NTL-Bibliothek  verwendet  (Stand  18.05.2007,  Version  5.4.1). 


[CLN]  Class  Library 
for  Numbers 


[GMP]  GNU  Multi- 
precision  Library 


4.3.3    Die  CLN  -  Bibliothek 

Die  CLN  -  Bibliothek12  wurde  von  Bruno  Haible13  entwickelt  und  wird  derzeit  von 
Richy  Kreckel14  betreut.  Sie  bietet  eine  Auswahl  an  elementaren  mathematischen 
Funktionen  für  Gleitpunktarithmetik  zur  Rechnung  mit  beliebig  einstellbarer  Stellen- 
genauigkeit. Nicht  enthalten  sind  Vektor  und  Matrixoperationen.  Zur  Untersuchung 
wurde  die  aktuellste  Version  der  CLN-Bibliothek  verwendet  (stand  18.05.2007,  Ver- 
sion 5.4.1).  Die  CLN-Bibliothek  verwendet  intern  die  GMP  .  Es  wurde  die  aktuellste 
Version  der  GMP  verwendet  (  stand  18.05.2007,  Version  4.2.1). 


4.3.4    Die  MAPM  -  Bibliothek 

Die  MAPM  -  Bibliothek15  wurde  von  Michael  C.  Ring16  an  der  Universität  von  Min- 
nesota17 entwickelt.  In  der  Bibliothek  sind  elementare  mathematische  Funktionen  ent- 
halten. Diese  Funktionen  arbeiten  mit  Fest  -  und  Gleitkommazahlen,  wobei  die  Stel- 

5  vgl.  dazu  [LiDIA] 

6  siehe  [TUD] 

7Es  wurde  die  aktuellste  Version  der  GMP  verwendet  (Veröffentlicht  201 1-05-08,  Version  gmp-5.0.2). 

8siehe  mehr  dazu  unter  http://www.cdc.informatik.tu-darmstadt.de/TI/LiDIA/#news,  Download  am 
13.12.2011 

"vgl.  dazu  [NTL] 
10 Victor  Shoup:  victor@shoup.net 
"siehe  [NYU] 
l2vgl.  dazu  [CLN] 

13Bruno  Haible:  haible@clisp.cons.org 
14Richy  Kreckl:  richard.kreckel@ginac.de 
15vgl.  dazu  [MAPM] 

16Michael  C.  Ring:  mike.ring@honeywell.com 
''siehe  [UOM] 


4.4  Untersuchung  des  Funktionsumfangs 
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lengenauigkeit  frei  wählbar  ist.  Zur  Untersuchung  wurde  die  aktuellste  Version  der 
MAPM-Bibliothek  verwendet  (stand  18.05.2007,  Version  4.9.2). 

4.3.5    Die  GMP  -  Bibliothek 

[GMP]  GNU  Multi- 

Die  GMP-Bibliothek  ist  eine  weitere  Bibliothek  zur  hochgenauen  Rechnung.  Sie  bie-  Precislon  Precision 
tet  Unterstützung  für  zahlreiche  Hardwareplattformen  und  Compiler.  Wie  viele  andere 
Bibliotheken,  wurde  sie  ursprünglich  in  der  Programmiersprache  C  verfasst.  Mittler- 
weile liegt  eine  C++-Adapter- Klasse  vor,  bei  der  alle  gängigen  Operatorüberladungen 
vorhanden  sind.  Für  ausgewählte  Hardwarearchitekturen  wurde  mit  Hilfe  von  Mine- 
Assembler  die  Geschwindigkeit  erhöht.  Für  alle  verwendeten  Berechnungen  wurde  die 
Version  gmp-5.0.2  (veröffentlicht  am  08.05.201 1)  verwendet. 

4.4    Untersuchung  des  Funktionsumfangs 

In  den  nachfolgenden  Unterpunkten  werden  die  in  Abschnitt  4.3  vorgestellten  Biblio- 
theken hinsichtlich  ihres  Funktionsumfangs  gegenübergestellt.  Dieser  Vergleich  be- 
zieht sich  lediglich  auf  /loat-Operationen.  Um  dem  Vergleich  übersichtlicher  zu  ge- 
stalten, wurden  die  Funktionen  wie  folgt  gruppiert: 

•  Grundrechenarten 

Diese  stellen  Grundoperationen  wie  Addition,  Subtraktion,  Multiplikation  und 
Division  auf  Basis  des  entsprechenden  Datentyps  dar. 

•  Erweiterte  mathematische  Funktionen 

In  dieser  Gruppe  sind  alle  trigonometrischen,  hyperbolischen,  logarithmischen 
und  exponentiellen  Funktionen  enthalten. 

4.4.1  Basisoperationen 

In  Tabelle  4.3  werden  die  jeweils  vorhanden  Basisoperationen  der  hier  untersuchten 
Bibliotheken  dargestellt. 


Funktion 

Befehl 

LiDIA 

NTL 

CLN 

MAPM 

GMP 

Addition 

+ 

Subtraktion 

Multiplikation 

Division 

/ 

Quadratur 

quad 

Inversion 

invert 

sqrt 

cuberoot 

Potenzieren 

pow 

Betrag 

fabs 

Signum 

signum 

Tabelle  4.3:  Vergleich  der  Basisoperationen 
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Alle  betrachteten  Bibliotheken  besitzen  Operatorüberladungen  für  Addition,  Sub- 
traktion, Multiplikation,  Division  und  Betrag.  Jedoch  fehlen  bei  der  GMP-Bibliothek 
alle  weiteren  grundlegenden  Funktionen,  wie  etwa  die  Quadratwurzel.  Die  NTL  -  Bi- 
bliothek ist  zusätzlich  eine  cuberoot-Funktion  implementiert,  welche  in  den  anderen 
Bibliotheken  fehlt.  Die  CLN  -  Bibliothek  besitzt  außerdem  eine  Signum  -Funktion, 
welche  in  den  anderen  Bibliotheken  nicht  enthalten  ist.  Da  bei  der  GMP-Bibliothek 
die  grundlegenden  mathematischen  Transformationen  nicht  enthalten  sind,  wird  sie 
für  die  folgenden  Vergleiche  ausgeklammert. 

4.4.1.1    Kompatibilität  mit  den  Namenskonventionen  der  mathematischen  Stan- 
dardfunktionen 

Bei  der  Implementierung  von  Programmen,  basierend  auf  multiprecision -Bibliotheken, 
fällt  auf,  dass  oftmals  die  Namenskonventionen  für  die  Standardfunktionen,  wie  sie  in 
C/C++-Standardbibliothek18  für  mathematische  Funktionen  definiert  sind,  nicht  oder 
nur  bedingt  eingehalten  werden.  Beispielsweise  hat  die  Funktion  zum  Potenzieren  (ab) 
einer  bigüoat-Zahl  in  der  LiDIA-Bibliothek  folgende  Bezeichnung: 

1       bigfloat   power(const   bigfloat  &a  ,    const   bigfloat  &b) ; 

Listing  4. 1 :  Power  Funktion  des  bigfloat-Datentyps 

Zum  Vergleich  ein  Auszug  aus  der  Standardbibliothek  für  den  doubJe-Datentyp: 
1       double  pow(const   double  &a ,    const   double  &b) ; 

Listing  4.2:  Power  Funktion  des  double-Datentyps 

Hier  unterscheidet  sich  lediglich  der  Funktionsname.  Würde  der  Funktionsname  der 
LiDIA-Bibliothek  pow  anstatt  power-  heißen,  dann  wäre  diese  Funktion  mit  der  ma- 
thematischen Standardbibliothek  kompatibel.  Diese  kleinen  Unterschiede  erschwe- 
ren die  Implementierung  von  Algorithmen  mit  C++-Templates,  da  hierfür  wrapper19- 
Funktionen  geschaffen  werden  müssen. 

4.4.2    Erweiterte  mathematische  Funktionen 

In  Tabelle  4.4  sind  die  jeweils  verfügbaren  transzendenten  Funktionen  eingetragen. 


Funktion 

Befehl 

LiDIA 

NTL 

CLN 

MAPM 

Exponential 

exp 

Logarithmus 

log 

Sinus 

sin 

Kosinus 

cos 

Tangens 

tan 

Kotangens 

cot 

Arcus  Sinus 

asin 

Arcus  Kosinus 

acos 

V 

Siehe  dazu  in  math.h  und  cmath.h 
"Dies  sind  Funktionen,  welche  ein  kompatibles  Interface  bereitstellen  und  ansonsten  keinerlei  Funk- 
tionalität besitzen. 
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Arcus  Tangens 

atan 

Arcus  Kotangens 

acot 

Sinus  Hyperbolicus 

sinh 

Kosinus  Hyperbolicus 

cosh 

Tangens  Hyperbolikus 

tanh 

Kotangens  Hyperbolicus 

coth 

Areasinus  Hyperbolicus 

asinh 

Areakosinus  Hyperbolicus 

acosh 

Areatangens  Hyperbolicus 

atanh 

Areacotangens  Hyperbolicus 

acoth 

Tabelle  4.4:  Vergleich  der  transzendenten  Funktionen 


Die  LiDIA-Bibliothek  enthält  alle  Standardfunktionen  und  weist  somit  den  größten 
Funktionsumfang  auf.  Ansonsten  besitzen  CLN  und  MAPM  den  selben  Funktionsum- 
fang. Am  wenigsten  Funktionen  bietet  die  NTL  -  Bibliothek,  in  der  keine  Umkehr  und 
Hyperbolikus  -  Funktionen  implementiert  sind.  Diese  könnten,  falls  nötig,  mit  Hilfe 
von  Additionstheoremen  nachgebildet  werden.  Davon  soll  hier  jedoch  abgesehen  wer- 
den. Allein  aus  dieser  Übersicht  kann  gefolgert  werden,  dass  die  LiDIA-Bibliothek 
als  einzige  geeignet  ist,  um  mathematische  Transformationen,  wie  sie  in  der  Geodäsie 
und  der  Himmelsmechanik  beispielsweise  zu  Bezugssystemtransformationen  benötigt 
werden,  mit  hoher  Anzahl  signifikanter  Nachkommastellen  durchzuführen. 

4.5    Untersuchung  zur  Abarbeitungsgeschwindigkeit 

Im  Folgenden  sollen  die  multiprecision -Bibliotheken  aufgrund  ihrer  Abarbeitungs- 
geschwindigkeit untersucht  werden.  Hierfür  wurden  synthetische  Benchmarks  ent- 
wickelt, um  sowohl  die  Basisoperationen  als  auch  die  transzendenten  Funktionen  mit 
unterschiedlichen  Genauigkeiten  auf  der  TP120  miteinander  vergleichen  zu  können.      [TP]  Testplattform 

Begriffsdefinition  DEF4.1  „Synthetischer  Softwarebenchmark": 

Ein  synthetischer  Softwarebenchmark  ist  ein  Computerprogramm  mit  dem  Zweck,  die  Leistungs- 
fähigkeit unterschiedlicher  Systeme  bezüglich  der  Ausführungsgeschwindigkeit  zu  vergleichen. 
Bei  einem  Softwarebenchmark  wird  derselbe  Algorithmus  mit  Hilfe  verschiedener  Bibliotheken 
ausgeführt  und  deren  Abiaufzeiten  gemessen.  Die  gemessenen  Abiaufzeiten  stellen  vergleich- 
bare Leistungsmerkmale  der  unterschiedlichen  Bibliotheken  dar. 

4.5.1  Grundrechenarten 

In  diesem  Abschnitt  werden  die  vier  Grundrechenarten  einer  Leistungsmessung  unter- 
zogen. Dabei  wird  bei  einer  jeweils  vorgegebenen  Genauigkeit  eine  bestimmte  Grund- 
rechenart (z.B.  Addition)  10000  mal  durchgeführt  und  der  dafür  benötigte  zeitliche 
Aufwand  gemessen.  Außerdem  wurde  für  jede  der  untersuchten  Bibliotheken  die  An- 
zahl der  signifikanten  Nachkommastellen  von  15  bis  150  sukzessive  erhöht. 


'Die  genauen  Leistungsmerkmale  der  Testplattformen  sind  in  Abschnitt  A.l  angegeben. 
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4.5.1.1  Addition 


60  SO  100 

signirilcante  Nachkommastellen 
-""MÄPM :V" Nt'L 'i CLN □ GMP" 


Abbildung  4.1:  Leistungsmessungen  der  Addition  auf  Testplattform  1 


Bei  der  Addition  ist  die  MAPM-Bibliothek  im  gesamten  Intervall  um  Faktor  10000 
langsamer  als  die  GMP-Bibliothek.  Die  NTL,  LiDIA  und  CLN-Bibliotheken  liegen  bei 
allen  untersuchten  Genauigkeiten  in  einem  Intervall  zwischen  100  und  500  ms.  Als 
schnellste  Bibliothek  geht  bei  der  Additionsoperation  die  GMP-Bibliothek  als  bessere 
hervor. 


4.5.1.2  Multiplikation 

Beim  Test  zur  Multiplikation  zeigt  sich  ein  ähnliches  Bild  wie  bei  der  Addition.  Die 
MAPM-Bibliothek  ist  deutlich  langsamer  als  alle  anderen  Bibliotheken.  Gegenüber 
der  schnellsten  Bibliothek  (CLN)  ist  die  MAPM-Bibliothek  um  den  Faktor  10  langsa- 
mer. Die  GMP  und  CLN-Bibliothek  sind  fast  gleich  schnell  und  die  LiDIA-Bibliothek 
ist  langsamer  als  die  NTL-Bibliothek. 


4.5.1.3  Subtraktion 

Wird  der  Test  zur  Subtraktion  betrachtet,  so  bietet  sich  ein  ähnliches  Bild  wie  bei  den 
vorausgegangenen  Untersuchungen.  Die  MAPM-Bibliothek  ist  um  Faktor  10  langsa- 
mer als  die  schnellste  (GMP)  Bibliothek,  NTL  und  CLN  sind  in  etwa  gleich  schnell 
und  die  LiDIA-Bibliothek  benötigt  im  Mittel  300  Millisekunden  für  einen  Testdurch- 
lauf. 


4.5.1.4  Division 

Beim  Test  zur  Division  ist,  ganz  im  Gegensatz  zu  den  vorausgegangenen  Tests,  die 
MAPM-Bibliothek  am  schnellsten.  Die  GMP-Bibliothek  wird  mit  zunehmender  An- 
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60  80  100 

signifikante  Nach  komm  a  stellen 
"MÄPM "NTL" * CLN""^^ 


Abbildung  4.2:  Leistungsmessungen  der  Multiplikation  auf  Testplattform  1 


Subtraktion 

1000  |  1  1  1  1  


E  100 


10   I  1  1  1  1  1  1  L_ 

20  40  60  80  100  120  140 

signifikante  Nachkommastellen 

ruPi'Ä "i mäPm vr" Wl ':k cln □ Gfcip ■ I 


Abbildung  4.3:  Leistungsmessungen  der  Subtraktion  auf  Testplattform  1 

zahl  signifikanter  Nachkommastellen  langsamer.  Am  langsamsten  ist  die  LiDIA  -  Bi- 
bliothek. Die  CLN-  u.  NTL  -  Bibliothek  liegen  nahe  an  der  Geschwindigkeit  der 
MAPM-Bibliothek  und  weisen  durchwegs  gut  Geschwindigkeitswerte  auf. 

Allgemein  betrachtet  ist  die  MAPM-Bibliothek  für  Addition,  Subtraktion  und  Multi- 
plikation nicht  geeignet,  da  alle  anderen  Bibliotheken  bessere  Leistungsdaten  aufwei- 
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10000 


100 


10   I  1  1  1  1  1  1  1  1 

20  40  60  80  100  120  140 

signifikante  Nachkommastellen 
iTJDTÄ "i MÄPM" >V" NTL e EINT ä GMP ■ j 

Abbildung  4.4:  Leistungsmessungen  der  Division  auf  Testplattform  1 

sen.  Des  Weiteren  ist  die  GMP-Bibliothek,  gefolgt  von  der  CLN-Bibliothek,  durch- 
wegs sehr  performant.  Außerdem  ist  die  LiDIA-Bibliothek  in  den  meisten  Fällen  im 
hinteren  Drittel  angesiedelt.  Weitere  Ergebnisse  zu  Laufzeitmessungen  der  C++  In- 
krement  und  Dekrement  -  Funktionen,  in  Abhängigkeit  unterschiedlicher  dezimaler 
Genauigkeiten,  sind  im  Anhang  F.5  zu  finden. 

4.5.2  Erweiterte  mathematische  Funktionen 

Hier  sollen  die  erweiterten  mathematischen  Funktionen  einer  Leistungsmessung  unter- 
zogen werden.  Dazu  wird  analog  zur  vorausgegangen  Untersuchung  (Abschnitt  4.5.1) 
ein  synthetischer  Benchmark  einer  jeweiligen  Funktion  durchgeführt  und  deren  Aus- 
führungsgeschwindigkeit gemessen.  Die  Ergebnisse  dieser  Messungen  für  die  Funk- 
tionen log,  sin,  cos  und  tan  werden  im  Folgenden  diskutiert.  Die  Resultate  zusätzlicher 
Funktionen21  sind  in  Abb.  F.5  und  F.6  (ab  Seite  221)  dargestellt.  Bei  dieser  Untersu- 
chung wurde  die  GMP-Bibliothek  nicht  einbezogen,  da  dieser  die  hierfür  notwendigen 
Funktionen  fehlen. 

4.5.3  Logarithmus 

Bei  den  Messungen  der  Jog-Funktion  (siehe  Abb.  4.5)  ist  die  MAPM-Bibliothek  über 
den  gesamten  Bereich  um  Faktor  100  langsamer  als  die  CLN-Bibliothek.  Die  LiDIA- 
Bibliothek  ist  um  Faktor  10  langsamer  als  die  CLN-Bibliothek  und  signifikant  langsa- 
mer als  die  NTL-Bibliothek.  Insgesamt  ist  die  CLN-Bibliothek  bei  diesem  Versuch  die 
schnellere.  Auffällig  sind  die  sprunghaften  Anstiege  bei  der  MAPM-Bibliothek  im  Be- 
reich von  30  und  120  signifikanten  Nachkommastellen  und  bei  der  LiDIA-Bibliothek 


exp,sqrt,asin,acos,atan,sinh,cosh,tanh 
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80  100 
signifilcante  Nachkommastellen 
""MÄPM "NTL 'i CLN" 


Abbildung  4.5:  Ergebnisse  der  Laufzeitmessungen  der  iog-Funktion  (Testplattform  1) 


im  Bereich  von  16,  70  und  150  Nachkommastellen. 


4.5.3.1  Sinus 


60  BO  100 

slgnifilcante  Nachkommastellen 
Li'D'IÄ 'i MÄPM "NTL 'i CL! 


Abbildung  4.6:  Ergebnisse  der  Laufzeitmessungen  der  sin-Funktion  (Testplattform  1) 


Werden  die  Laufzeitmessungen  (siehe  Abb.  4.6)  genauer  betrachtet,  so  fällt  auf, 
dass  bei  allen  Bibliotheken  die  Laufzeit  mit  zunehmender  Anzahl  signifikanter  Nach- 
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kommastellen  steigt.  Dennoch  erscheint  die  CLN  -  Bibliothek  am  schnellsten,  gefolgt 
von  der  LiDIA-Bibliothek.  Besonders  langsam  ist  in  diesem  Fall  die  NTL-Bibliothek. 
Diese  ist  um  Faktor  100  langsamer  als  die  CLN-Bibliothek. 

4.5.3.2  Kosinus 


100   I  1  1  1  1  1  1  ' — 

20  40  60  BO  100  120  140 

slgnifilcante  Nachkommastellen 


Abbildung  4.7:  Ergebnisse  der  Lauf  Zeitmessungen  der  cos  -Funktion  (Testplattform  1) 

Die  Messungen  zur  Kosinusfunktion  (siehe  Abb.  4.7)  ist,  verglichen  mit  den  Mes- 
sungen zur  Sinusfunktion  nahezu  identisch.  Hierbei  zeigt  sich  wieder  die  Schwäche 
der  NTL  und  MAPM-Bibliothek  hinsichtlich  trigonometrischer  Funktionen. 

4.5.3.3  Tangens 

Die  Laufzeitmessung  zur  Tangensfunktion  (siehe  Abb.  4.8)  wurde  ohne  die  NTL- 
Bibliothek  durchgeführt,  da  diese  keine  tan-Funktion  bereitstellt.  Hierbei  ist  die  CLN- 
Bibliothek  im  gesamten  Bereich  um  Faktor  100  schneller  als  die  MAPM-Bibliothek. 

4.6  Fazit 

Die  Frage,  welche  Bibliothek  am  geeignetsten  für  diese  Arbeit  ist,  lässt  sich  nicht  pau- 
schal beantworten.  Würde  ausschließlich  die  Abarbeitungsgeschwindigkeit  eine  Rolle 
bei  der  Auswahl  spielen,  dann  wäre  die  CLN-Bibliothek  die  erste  Wahl.  Diese  besitzt 
jedoch,  verglichen  mit  der  C/C++-Standardbibliothek,  nicht  alle  notwendigen  mathe- 
matischen Transformationen,  die  für  diese  Arbeit  notwendig  sind.  Außerdem  kann  bei 
der  CLN-Bibliothek  die  jeweilig  verwendete  numerische  Genauigkeit  nicht  direkt  ein- 
gestellt werden,  d.h.  die  numerische  Genauigkeit  wird  automatisch  bei  der  Initialisie- 
rung von  Variablen  gesetzt.  Dies  wird  an  dieser  Stelle  als  weiterer  Nachteil  gewertet. 


4.6  Fazit 
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Tangens 

100000   |  1  1  1  ,  


100  I  1  1  1  1  1  1  1  1 

20  40  60  80  100  120  140 

signifilcante  Nachkommastellen 
:  "ÜDI'Ä 'i "MÄPM ;V" 'MtL' ä CLN"  — e— "| 

Abbildung  4.8:  Ergebnisse  der  Laufzeitmessungen  der  tan-Funktion  (Testplattform  1) 

Die  LiDIA-Bibliothek  ist  beim  Laufzeitvergleich  in  vielen  Fällen  hinter  der  CLN- 
Bibliothek,  besitzt  jedoch  den  vollen  Funktionsumfang  der  C/C++-Standardbibliothek. 
Besonders  bei  den  trigonometrischen  Umkehrfunktionen  (siehe  F.  11),  welche  häufig 
bei  Bezugssystemtransformationen  benötigt  werden,  ist  die  LiDIA-Bibliothek  schnel- 
ler. Abgesehen  von  kleineren  Abweichungen  in  der  Nomenklatur  der  Standardfunktio- 
nen erscheint  diese  Bibliothek  am  geeignetsten. 

Die  hierfür  angestellten  Vergleiche  decken  nur  einen  Bruchteil  der  verfügbaren  Funk- 
tionen der  untersuchten  Bibliotheken  ab.  Außerdem  wurden  nur  zwei  Kriterien  zur 
Validierung  herangezogen.  Weitere  mögliche  Kriterien  wären: 

•  Welchen  Umfang  und  Qualität  besitzt  die  Dokumentation  der  jeweiligen  Biblio- 
thek. 

•  Wurde  die  untersuchte  Bibliothek  weiterentwickelt  und  in  anderen  Projekten 
aktiv  eingesetzt? 

•  Ist  die  Bibliothek  für  eine  bestimmte  Plattformen  optimiert? 

•  Wie  aktuell  ist  die  bestehende  Version,  d.h.  wann  war  die  letzte  Aktualisierung? 

•  Gibt  es  ein  Forum,  in  dem  die  Anwender  Fragen  an  die  Entwickler  stellen  kön- 
nen? 

•  Ist  die  Bibliothek  mit  den  aktuellen  Compilern  kompatibel? 

•  Für  welche  Plattformen  ist  die  Bibliothek  verfügbar? 

•  Unterstützt  die  Bibliothek  bereits  Optimierungen  für  64-Bit  Arithmetik? 


100 


Kapitel  4:  Eignung  von  muitiprecision-BiBLiOTHEKEN 


Die  Beantwortung  dieser  Fragen  würde  den  Rahmen  dieser  Arbeit  sprengen. 
Außerdem  könnten  zur  Leistungsmessung,  ganz  im  Gegensatz  zur  Laufzeitmessung, 
auch  die  Anzahl  der  Prozessortaktzyklen  aufgezeichnet  werden  und  diese  als  weiteres 
Qualitätskriterium  herangezogen  werden.  Hierzu  wird  auf  [Agner]  verwiesen,  dort  ste- 
hen die  nötigen  Softwareroutinen  und  umfangreiches  Informationsmaterial  zur  Mes- 
sung der  Taktzyklen  und  zur  Programmoptimierung  bereit. 

Weiterhin  wird  noch  auf  die  Veröffentlichung  von  [Zimmermann98]  hingewiesen,  worin 
[CAS]      Computer  multiprecision -Bibliotheken  und  CAS  u.a.  aufgrund  ihrer  Abarbeitungsgeschwindig- 
Aigebra  Systeme  j  ^  integerrechnung  miteinander  verglichen  werden. 
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Methoden  zur  Laufzeitverbesserung  von 
Programmen 


Schwerpunkt  des  Kapitels: 

Ziel  dieses  Abschnitts  ist  es,  Strategien  zur  Programmoptimierung  für  Desktop- 
Computer  und  Workstations  bereitzustellen.  Diese  sind,  verglichen  mit  Hochleistungs- 
rechnern, nicht  so  leistungsfähig,  aber  weiter  verbreitet  und  stehen  folglich  einer  grö- 
ßeren Nutzergemeinde  zur  Verfügung. 

Hierfür  wird  der  Entwicklungsprozess  eines  Programms  kategorisiert  und  in  mehrere 
Phasen  unterteilt.  In  jeder  dieser  Entwicklungsphasen  gibt  es  gewisse  Techniken,  um 
die  Ablaufgeschwindigkeit  eines  Programms  auf  einer  bestimmten  Zielarchitektur  zu 
beeinflussen.  Diese  werden  erst  beschrieben  und  anschließend  anhand  einschlägiger 
Fallbeispiele  erklärt.  Grundlegend  soll  zwischen  folgenden  Methoden  zur  Laufzeit- 
verbesserung unterschieden  werden: 

•  C++  Templatemetaprogrammierung  [TMP] 

•  Einsatz  von  Hilfsmitteln  der  Parallelverarbeitung  mit  OpenMP 

•  Optimierung  durch  den  Compiler 
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5.1    Verschiedene  Arten  der  Optimierung 

Soll  ein  Programm  hinsichtlich  Abarbeitungsgeschwindigkeit  optimiert  werden,  so 
kann  dies  in  verschiedenen  Phasen  der  Programmentwicklung  durchgeführt  werden. 
Der  gesamte  Entwicklungsprozess,  bis  hin  zur  Laufzeit,  kann  in  drei  verschiedene 
Phasen  unterteilt  werden.  Am  Anfang  steht  die  Entwicklungsphase,  in  welcher  das 
Programm  in  einer  bestimmten  Programmiersprache  erstellt  wird.  Daraufhin  folgt  die 
Übersetzungsphase,  in  der  das  Programm  in  die  Maschinensprache  übersetzt  wird,  ge- 
folgt von  der  Laufzeitphase,  in  der  das  Programm  ausgeführt  wird.  Diese  Phasen  sind 
in  Abb.  5.1  dargestellt. 


\ 

\  \ 

Entwicklungsphase 

>  Ubersetzungsphase 

>  Laufzeitphase 

/ 

Ä 

Abbildung  5.1:  Entwicklungsphasen  bei  der  Erstellung  eines  Programms 


Während  der  Entwicklungsphase  gibt  es  verschiedene  Techniken  und  Vorgehens- 
weisen, die  helfen,  ein  Programm  zu  optimieren.  Diese  können  weiter  kategorisiert 
werden  und  stellen  hohe  Anforderungen  an  den  Programmierer.  Dieser  muss  an  der 
entsprechenden  Stelle  auf  die  richtige  Methode  zurückgreifen,  um  ein  Optimum  zu 
erreichen.  Hierbei  wird  darauf  geachtet,  dass  beispielsweise  unnötige  Rechenopera- 
tionen eingespart  werden  und  somit  die  Abarbeitungsgeschwindigkeit  des  optimierten 
Programms  erhöht  wird.  Viele  dieser  Techniken,  speziell  für  die  Programmiersprachen 
C  und  C++,  sind  in  [Agner]  zu  finden.  Im  Falle  der  Programmiersprachen  C  und  C++ 
ist  es  gängige  Praxis,  dass  Teile  des  Quellcodes  in  der  Maschinensprache  Assemb- 
ler1 eingefügt  werden,  um  somit  das  Programm  an  eine  bestimmte  Hardware  anzupas- 
sen. Des  Weiteren  gibt  es  spezielle  Techniken  der  Templatemetaprogrammierung  ,  mit 
der  die  Geschwindigkeit  eines  Programms  ebenfalls  erhöht  werden  kann.  Außerdem 
können  viele  Problemstellungen  parallelisiert  werden  und  dadurch  weitaus  höhere  Ge- 
schwindigkeiten erreichen,  als  ein  seriell  abarbeitendes  Programm.  Dazu  gibt  es  für 
die  Programmiersprachen  C  und  C++  die  zwei  verschiedenen  Techniken  OpenMP3 
und  MPI4. 

Ferner  wird  das  erstellte  Programm  in  der  Übersetzungsphase  einem  Compiler  über- 
geben, der  weitere  Optimierungen  durchführt  und  das  Programm  an  die  jeweilige 
Hardwareplattform  anpasst.  Dabei  gibt  es  eine  Vielzahl  von  Optimierungsoptionen, 
die  während  des  Übersetzens  aktiviert  werden  können.  Diese  bringen  auf  manchen 
Plattformen  bei  gewissen  Programmen  mehr  Geschwindigkeit,  jedoch  kann  keine  um- 
fassende Garantie  dafür  gegeben  werden.  Tatsache  ist,  dass  sich  manche  Optimie- 
rungsoptionen sogar  nachteilig  auf  die  Laufzeit  auswirken.  An  dieser  Stelle  bleibt  dem 
Programmierer  oft  nichts  anderes  übrig,  als  die  Dokumentation  des  Compilers  zu  stu- 
dieren. Um  diesen  Prozess  etwas  zu  vereinfachen  wird  auf  den  nächsten  Unterpunkt 

'siehe  mehr  dazu  unter  [Backer03] 
2  siehe  mehr  dazu  unter  [Stroustrup04] 

3siehe  mehr  dazu  unter  [Hoffmann08],[Rauber08]  und  [OpenMP] 
4siehe  mehr  dazu  unter  [Rauber08]  und  [MPIStandard] 
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hingewiesen,  in  welchem  eine  Möglichkeit  dargestellt  wird,  die  benötigten  Optimie- 
rungsoptionen automatisiert  zu  bestimmen. 

Nachdem  das  Programm  übersetzt  und  optimiert  ist,  kann  es  ausgeführt  werden  (Lauf- 
zeitphase). Besonders  bei  numerischen  Berechnungen  ist  es  oft  wichtig,  die  Zeitspanne 
zwischen  Start  und  Beendigung  des  Programms  so  gering  wie  möglich  zu  halten.  Soll 
nun  ein  Programm  optimiert  werden,  so  muss  festgestellt  werden,  welcher  Programm- 
teil die  meiste  Rechenzeit  in  Anspruch  nimmt.  Dies  kann  mit  sogenannten  proüling- 
Programmen  durchgeführt  werden.  Diese  messen  beispielsweise  während  der  Lauf- 
zeitphase die  Anzahl  und  Zeitdauer  bestimmter  Funktionsaufrufe  und  erstellen  daraus 
ein  Protokoll.  Aus  diesem  kann  der  Programmierer  die  Stellen  im  Programm  identi- 
fizieren, welche  die  meiste  Laufzeit  beanspruchen  und  diese  verbessern.  Im  Rahmen 
dieser  Arbeit  wurde  meist  das  profiiing-Programm  gprof5  aus  der  GNU-Compiler- 
Collection  verwendet.  Die  Vorgehensweise  und  der  Umgang  mit  diesem  hilfreichen 
Werkzeug  soll  anhand  eines  Beispiels  gezeigt  werden: 

Beispiel  5.1  „Identifikation  von  zeitintensiven  Programmstellen" 

Um  zeitintensive  Programmstellen  zu  identifizieren,  muss  das  Programm  zunächst  übersetzt 
werden.  Dabei  ist  es  erforderlich,  eine  bestimmte  Compileroption  (—pg)  zu  aktivieren.  Im  An- 
schluss  kann  das  Programm  gestartet  werden.  Dabei  wird  die  jeweilige  Anzahl  Funktions- 
aufrufe und  deren  Zeitdauer  mitprotokolliert  und  in  einer  Datei  abgelegt.  Diese  Datei  heißt 
standardmäßig  gmon.out  und  kann  dann  dem  Hilfsprogramm  gprof  übergeben  werden,  das 
aus  dem  Protokoll  und  dem  erstellten  Programm  einen  Analysereport  generiert.  Für  ein  Pro- 
gramm zur  Integration  des  Duffing  Oszillators  mit  Hilfe  des  Potenzreihenintegrators  unter  Ver- 
wendung des  Decimal-Datentyps  konnte  folgender  Analysereport  (siehe  Tabelle  5.1)  erstellt 
werden.  Hierbei  wird  lediglich  ein  kurzes  Extrakt  des  Analysereports  in  kompakter  Form  ge- 
zeigt. 


Zeit[%] 

Zeit  [s] 

Aufrufe 

Funktionsname 

37.93 

0.11 

186219 

Decimal  ::  mul(...) 

20.69 

0.06 

672403 

Decimal  ::  _rshift(...) 

6.90 

0.02 

670397 

Decimal  ::  _round{...) 

Tabelle  5.1:  Wichtige  Ergebnisse  der  gprof  Analyse 


Hierbei  ist  in  der  ersten  Spalte  der  prozentuale  Anteil  der  jeweiligen  Funktion  zur  Laufzeit 
angegeben.  Die  Funktion  Decimal  ::  mul(...)  nimmt  37,93%  der  Gesamtlaufzeit  in  Anspruch, 
wobei  alle  Funktionsaufrufe  zusammen  0.11  Sekunden  Laufzeit  beansprucht  haben  (Spalte  2). 
Außerdem  wurde  diese  Funktion  186219  mal  aufgerufen  (Spalte  3).  Aus  diesen  wenigen  Zeilen 
lassen  sich  einige  Erkenntnisse  gewinnen: 

•  Mögliche  Optimierungen  in  den  Funktion  Decimal  ::  mul(...)  und  Decimal  ::  _rshift(...) 
sind  lohnenswert,  da  diese  relativ  viel  Laufzeit  beanspruchen  (zusammen  über  50%). 

•  Ferner  wird  die  Funktion  Decimal  ::  _rshift(...)  sehr  oft  aufgerufen,  benötigt  aber 
weniger  Laufzeit  als  die  Funktion  Decimal  ::  mul(...).  Dadurch  könnte  bei  Reduktion 
der  Aufrufe  von  Decimal  ::  _rshift(...)  unnötige  Laufzeit  eingespart  werden. 

Wie  in  diesem  Beispiel  gezeigt,  stellt  ein  profiiing-Programm  ein  wertvolles  Werk- 
zeug zur  Optimierung  dar.  Weitere  profiiing-Programme  sind  u.a.  [CodeAnalyst]  und 
[Intel  VTune]. 


5  siehe  mehr  dazu  unter  [GProf] 
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5.2  Hard  -  und  Softwareplattform 

Begriffsdefinition  DEF5.1  „Plattform": 

Der  Begriff  Plattform  ist  ein  Überbegriff  der  Informatik  und  steht  für  eine  bestimmte  Zusam- 
menstellung aus  Rechnerarchitektur,  Programmiersprache  und  den  dabei  verwendeten  Biblio- 
theken mit  deren  Laufzeitumgebung.  Damit  kann  verschiedenen  Konstellationen,  bestehend  aus 
Hard.  u-  Softwarekomponenten,  ein  Name  zugeordnet  werden. 

Dieser  abstrakte  Begriff  kann  weiter  verfeinert  werden,  indem  zwischen  den  ver- 
wendeten Hard-  u.  Softwarekomponenten  unterschieden  wird. 

Begriffsdefinition  DEF5.2  „Hardwareplattform": 

Der  Begriff  Hardwareplattform  definiert  die  verwendete  Prozessorarchitektur  und  die  verwen- 
dete Hardware  im  Allgemeinen.  Hiermit  wird  beispielsweise  eine  einheitliche  Maschinenspra- 
che, Byte-Reihenfolge  und  Datenwortgröße  festgelegt. 

Begriffsdefinition  DEF5.3  „Softwareplattform": 

Durch  Festlegung  auf  bestimmte  Softwarekomponenten,  bestehend  aus  Betriebssystem,  Pro- 
grammiersprache und  Laufzeitumgebung,  wird  eine  bestimmte  Softwareplattform  definiert. 

Aufgrund  der  Vielzahl  verfügbarer  Hard-  und  Softwareplattformen  muss  eine  Ein- 
schränkung hinsichtlich  der  hier  aufgezeigten  Methoden  zur  Laufzeitverbesserung  ge- 
troffen werden:  Alle  durchgeführten  Methoden  führen  in  vielen  Fällen  zu  Laufzeitver- 
besserungen auf  Systemen  mit  x86-Prozessorarchitektur.  Sie  wurden  auf  Single-  und 
Dual-Core-Prozessoren  mit  32/64  Bit-Datenwortgröße  getestet.  Ferner  wurden  die  ent- 
wickelten Programme  auf  Linux  basierenden  Betriebssystemen6  (Ubuntu)  in  der  Pro- 
grammiersprache C  und  C++  entwickelt.  Damit  die  Laufzeitmessungen  wiederholbar 
sind,  befinden  sich  die  Eckdaten  der  verwendeten  Testplattformen  in  Abschnitt  A.l 
(Seite  183).  Folglich  kann  keine  Aussage  über  das  Laufzeitverhalten  dieser  Optimie- 
rungsmethoden auf  anderen  Plattformen  getroffen  werden. 

5.3  Optimierung  während  der  Entwicklungsphase 

Es  gibt  viele  Möglichkeiten,  die  resultierende  Laufzeit  eines  Programms  während  der 
Entwicklungsphase  zu  beeinflussen.  Dabei  können  die  jeweiligen  Maßnahmen  in  meh- 
rere Gruppen  eingeteilt  werden: 

•  Allgemeine  Optimierungstechniken 

Hier  können  eine  Reihe  von  Faustregeln  angegeben  werden,  welche  helfen,  die 
Laufzeit  eines  Programms  zu  beschleunigen. 

1 .  Jeder  Zugriff  auf  das  Dateisystem  benötigt  kostbare  Laufzeit,  damit  sollte 
demnach  sparsam  umgegangen  werden. 

2.  Jeder  Funktionsaufruf  kostet  Laufzeit.  Aus  diesem  Grund  sollten  kleine 
Funktionen,  die  häufig  aufgerufen  werden,  mit  einem  inline  -  Schlüssel- 
wort versehen  werden. 

6Folgende  Compiler  wurden  verwendet:  GCC,  clang  und  Intel-Compiler. 


5.3  Optimierung  während  der  Entwicklungsphase 


105 


3.  Das  Kopieren  von  Objekten  kostet  unnötige  Laufzeit.  Aus  diesem  Grund 
sollten  Referenzen  bzw.  konstante  Referenzen  bevorzugt  verwendet  wer- 
den. Ist  es  dennoch  nötig  ein  Objekt  zu  kopieren,  dann  sollte  der  Konstruk- 
tor und  nicht  der  Zuweisungsoperator  verwendet  werden,  da  letzterer  i.d.R. 
mehr  Funktionsaufrufe  und  folglich  mehr  Laufzeit  beansprucht. 

4.  Jede  Berechnung  bzw.  Vereinfachung,  die  schon  in  der  Entwicklungsphase 
durchgeführt  werden  kann,  sollte  schon  während  dieser  durchgeführt  wer- 
den. Wird  die  Berechnung  in  die  Übersetzungsphase  verlagert,  d.h.  dem 
Compiler  überlassen,  steigt  die  Übersetzungszeit  u.U.  unnötig  an. 

5.  Das  Anlegen  einer  Variablen  kostet  Laufzeit,  da  hierfür  Speicher  ange- 
fordert werden  muss.  Aus  diesem  Grund  ist  es  empfehlenswert,  unnötige 
Variablen  zu  sparen. 

Diese  Techniken  können  natürlich  weiter  ausgebaut  werden.  In  [Bulka99]  wird 
anhand  vieler  Beispiele  aufgezeigt,  wie  aufgrund  der  bereits  gezeigten  Techni- 
ken (und  mehr)  Geschwindigkeitsengpässe  vermieden  werden  können.  Außer- 
dem wird  vor  möglicher  falscher  Herangehensweise  zur  Optimierung  gewarnt. 
Hier  ein  kurzer  Auszug  aus  [Bulka99]  (Seite  134): 


80-20  Rule:  Speed  Up  the  Common  Path 

The  80-20  rule  has  many  applications:  80%  of  the  execution  scenarios  will  tra- 
verse  only  20%  of  your  source  code,  and  80%  of  the  elapsed  time  will  he  spent 
in  20%  of  the  functions  encountered  on  the  execution  path.  The  80-20  rule  is 
the  dominating  force  driving  the  argument  that  premature  tuning  is  a  sin.  If  you 
randomly  tune  everything  you  can  think  of,  not  only  do  you  waste  80%  of  the 
effort,  you  will  also  hack  the  design  beyond  repair. 

•  Spezielle  Optimierungstechniken 


-  Parallelverarbeitung 

Falls  ein  Problem  in  verschiedene  parallele  Aufgaben  unterteilt  werden 
kann,  bieten  sich  die  beiden  Parallelisierungstechniken  OpenMP7  und  MPI8 
an.  Mit  ersterer  können  sowohl  Schleifen  als  auch  Funktionsblöcke  paral- 
lelisiert  werden.  Diese  Art  der  Parallelisierung  wird  auch  als  shared  memo- 
ry-Parallelisierung  bezeichnet,  da  hierbei  nur  ein  Programmspeicher  für 
alle  parallel  arbeitenden  Ablauffäden  (threads)  vorhanden  ist.  Ganz  im  Ge- 
gensatz zum  MPI,  denn  dort  wird  die  Parallelität  mit  Hilfe  von  Prozessen  [mpi]  Message 
realisiert.  Diese  besitzen  ihren  eigenen  Speicherbereich  und  können  auch  £assing  Interface 
auf  verschiedenen  Computern  laufen.  Darum  wird  MPI  auch  als  distribu- 
ted  memory-Parallelisierung  bezeichnet. 

-  Metaprogrammierungstechniken 

Der  Begriff  Metaprogrammierung  steht  i.A.  für  Programmiertechniken, 

7  siehe  mehr  dazu  unter  [OpenMP] 

8  siehe  mehr  dazu  unter  [MPIStandard] 
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bei  denen  aus  einem  Quelltext  wieder  Quelltext  erzeugt  bzw.  generiert 
wird.  Unter  Templatemetaprogrammierung  [TMP]  versteht  man  einen  spe- 
ziellen Teil  der  Programmiersprache  C++.  Hierbei  kann  mit  Hilfe  der  Spra- 
che C++  wiederum  C++-Quelltext  generiert  werden.  Dies  ist  nicht  mit  Ma- 
kroprogrammierung  aus  der  Programmiersprache  C  zu  verwechseln,  da 
hier  überwiegend  C++-Templates  verwendet  werden  und  diese  während 
der  Übersetzungsphase  einer  syntaktischen  Prüfung  unterzogen  werden. 
Damit  ist  es  möglich,  den  Präprozessor  eines  C++-Compilers  zur  Quell- 
textgenerierung  zu  verwenden,  um  in  der  Übersetzungsphase  einen  Quell- 
text zu  generieren,  der  das  zugrunde  liegende  Problem  effizienter  löst.  Die- 
se Art  der  Programmierung  bietet  also  die  Möglichkeit,  ein  Programm  zu 
schreiben,  welches  sich  selbst  verändert,  bevor  es  zur  Ausführung  (Lauf- 
zeitphase) kommt. 

-  Einsatz  von  Maschinensprache  (Assembler) 

Diese  Optimierungstechnik  kann  verwendet  werden,  um  an  gewissen  Stel- 
len im  Quellcode  direkt  in  Maschinensprache  zu  programmieren.  Sie  wird 
i.A.  nur  angewendet,  falls  die  Optimierung  des  Compilers  nicht  das  ge- 
wünschte Resultat  erbringt.  Allerdings  birgt  diese  Art  der  Optimierung 
auch  einige  Tücken,  da  durch  die  Verwendung  der  Maschinensprache  die 
Software  auf  eine  bestimmte  Hardwareplattform  optimiert  wird,  was  zu 
Portabilitätsproblemen  führen  kann.  Somit  kann  nicht  garantiert  werden, 
dass  dieses  Programm  auf  einer  anderen  Hardwareplattform  ein  ähnliches 
Laufzeitverhalten  besitzt.  Soll  beispielsweise  eine  Subroutine  in  Maschi- 
nensprache programmiert  werden,  so  gilt  es,  einen  optimalen  Satz  an  Ma- 
schinensprachbefehlen zu  finden,  der  das  Problem  auf  der  jeweiligen  Hard- 
wareplattform möglichst  effizient  löst.  Hierbei  können  sogenannte  super- 
optimizer9  helfen.  Diese  sind  Programme,  die  durch  exzessives  Suchen 
und  Messen  des  Laufzeitverhaltens  den  optimalen  Satz  an  Maschinen- 
sprachbefehlen ermitteln. 

5.3.1    C++-Templatemetaprogrammierung  [TMP] 

Bei  dieser  Programmiertechnik  wird  darauf  geachtet,  möglichst  alle  Informationen, 
welche  für  die  Übersetzungsphase  festgelegt  und  somit  statisch  im  Quelltext  (Metada- 
ten) vorhanden  sind,  auszunutzen  um  daraus  das  Programm  zu  verändern.  Hierbei  soll 
die  Veränderung  in  einem  schnelleren  und  besser  optimierten  Programm  liegen.  Die- 
se Technik  der  gezielten  Ausnutzung  statischer  Informationen  wurde  1994  von  Erwin 
Unruh  entdeckt10. 

Begriffsbestimmung  BEG5.1  „Metadaten": 

Dies  sind  Daten,  die  während  der  Übersetzungsphase  manipuliert  werden  können,  d.h.  Typen, 
Referenzen,  Zeiger,  konstante  Elemente  und  Klassenelemente. 

5.3.1.1    Arbeitsweise  eines  C++-Templatemetaprogramms 


'siehe  mehr  dazu  unter  [JoshiOl],  [BrainOö]  und  [Bansal06] 
"siehe  mehr  dazu  unter  [Unruh94] 
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•  Statische 
Information 


Übersetzung 


Abbildung  5.2:   Schematischer  Ablauf  zum  Übersetzungsvorgang  eines  C++- 
Templatemetaprogramms 

Der  Übersetzungsvorgang  eines  C++-TMP  kann  in  zwei  aufeinander  folgende  Pha-  [TMP]  Temptatemeta- 
sen  unterteilt  werden,  was  in  Abb.  5.2  illustriert  ist:  Programm 

1.  Im  ersten  Schritt  erfolgt  die  Instanziierunsphase.  Dabei  werden  die  erzeugten 
Templates  durch  den  C++-Präprozessor  interpretiert.  In  dieser  Phase  erfolgt  die 
Veränderung  des  Programms,  da  der  Präprozessor  bestimmte  Konstrukte  rekur- 
siv ersetzt.  Durch  Ausnutzung  dieser  Eigenschaft  kann  sich  ein  Programm  wäh- 
rend der  Übersetzungsphase  selbst  umschreiben. 

2.  Anschließend  erfolgt  die  Interpretation  mit  darauf  folgender  Umwandlung  in 
Maschinencode.  Dies  geschieht  analog  zum  Übersetzen  eines  herkömmlichen 
C++  Programms. 

1  template  <typename  T>  void  Square  (VectorT<T>  &a) 


Beispiel  5.2  für  Anwendung  von  TMP  auf  Schleifen" 

In  diesem  einführenden  Beispiel  zur  C++-Metaprogramierungs-Technik  soll  kurz  die  Grundi- 
dee anhand  der  Vereinfachung  von  Schleifen  während  der  Ubersetzungsphase  gezeigt  werden. 
Diese  Technik  wird  auch  bei  Compilern  zur  Optimierung  eingesetzt  und  dort  als  loop-unrolling 
bezeichnet.  In  Listing  5.1  wird  ein  Ausschnitt  einer  C++  Funktion  gegeben,  welche  das  Qua- 
drat einer  gegebenen  Potenzreihe  berechnet.  Der  formelmäßige  Zusammenhang  zur  Quadratur 


2  { 
3 
4 
5 
6 
7 
8 
9 
10 

11  } 


VectorT<T>  v(a)  ; 

for(unsigned    int  n=0;  n  <  v.uiSizeQ;  n++) 


for ( unsigned    int    i=0;    i  <=  n;    i ++) 


a[n]  +=  v[i]   *  v[n— i]; 


Listing  5.1:  Square  Funktion  (Version  1) 
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einer  Potenzreihe  ist  in  Abschnitt  2.4.2  ab  Seite  31  angegeben.  Die  hier  verwendete  Funktion 
wurde  für  dieses  Beispiel  vereinfacht  und  entstammt  dem  PowerSeriesT-Modul.  Werden  die 
beiden  for-Schleifen  in  den  Zeilen  4  und  6  betrachtet,  so  iterieren  diese  jeweils  über  eine  be- 
stimmte Anzahl  von  VectorT<T>n -Elementen.  Die  Anzahl  der  VectorT<T>-Elemente  ist  in 
diesem  Fall  nicht  statisch  vorhanden  und  wird  demnach  zur  Laufzeitphase  abgefragt.  Um  die- 
se Funktion  in  ein  Templatemetaprogramm  zu  wandeln  ist  es  im  ersten  Schritt  erforderlich,  die 
Anzahl  der  VectorT<T> -Elemente  zur  Übersetzungszeit  zu  kennen.  In  einer  leicht  veränderten 
Version  (siehe  Listing  5.2)  wurde  die  VectorTMP '-Klasse12  verwendet,  welche  die  Anzahl  der 
Elemente  (N)  zur  Übersetzungsphase  statisch  zur  Verfügung  stellt13.  Durch  diese  Modifikation 
werden  dem  Compiler  die  nötigen  Informationen  bereit  gestellt,  um  einen  besser  optimierten 
Maschinencode  zu  erzeugen.  Somit  ist  es  nicht  mehr  nötig,  die  beiden  for-Schleifen  während 
der  Laufzeitphase  iterieren  zu  lassen.  In  Version  2  wird  diese  Aufgabe  dem  Compiler  über- 
lassen, welcher  je  nach  Optimierungseinstellungen  mehr  oder  weniger  stark  optimiert.  Soll  si- 
chergestellt werden,  dass  die  Schleifen  während  der  Übersetzungsphase  vereinfacht  werden,  so 
kann  man  dies  mit  rekursiv  definierten  Template-Metafunktionen  gewährleisteten.  Hierzu  wur- 
de eine  weitere  Version  (siehe  Listing  5.3)  erstellt,  welche  auf  der  zweiten  Version  basiert,  je- 
doch mit  Hilfe  von  Template-Metprogrammierung  erzwingt,  dass  die  äußere  Schleife  während 
der  Übersetzungsphase  vereinfacht  wird.  Da  sich  die  Template-Metaprogrammierungstechnik 
von  der  herkömmlichen  C++ -Templateprogrammierung  in  vielen  Punkten  unterscheidet,  soll 
hier  die  Funktionsweise  der  Version  3  erklärt  werden: 

•  Zeile  13-18 

In  den  Zeilen  13  und  14  ist  analog  zu  den  Versionen  2  und  3  die  Funktion  Square  de- 
finiert. In  Zeile  15  wird  eine  Kopie  des  VectorTMP<T>-Objects  angelegt  und  in  Zeile 
17  erfolgt  der  Aufruf  der  äußeren  for-Schleife,  welche  hier  als  OuterLoop  bezeichnet 
wird.  Diese  Funktion  enthält  zwei  Template-Parameter:  an  erster  Stellen  den  Datentyp 
(T)  und  zweitens  den  Startindex  der  Schleife  mit  dem  Wert  0.  Außerdem  besitzt  diese 
Funktion  zwei  Funktionsparameter  vom  Typ  VectorTMP <T>  (siehe  mehr  dazu  in  Zeile 
1-3). 

•  Zeile  1-3 

Dies  ist  die  Funktionsdeklaration  der  Funktion  OuterLoop  mit  den  beiden  Template- 
Parametern  T  und  n  und  den  Funktionsparametern  vom  Typ  VectorTMP <T>.  Hierbei 
ist  der  zweite  Parameter  als  konstante  Referenz  definiert,  d.h.  der  Wert  dieses  Objekts 
kann  innerhalb  dieser  Funktion  nicht  verändert  werden,  was  eine  Art  Schreibschutz 
darstellt  und  dem  Compiler  zusätzlich  bei  der  Optimierung  hilft. 

•  Zeile  5-7 

In  den  Zeilen  5  und  6  wird  die  innere  Schleife  abgearbeitet.  Hierbei  gibt  es  keinen  Unter- 
schied zu  den  anderen  beiden  Versionen.  In  Zeile  7  wird  die  Funktion  OuterLoop  erneut 
aufgerufen.  Diese  erzwingt  eine  Rekursion  während  der  Instanziierunsphase,  welche 
Teil  der  Übersetzungsphase  ist.  Dabei  erfolgt  der  Aufruf  mit  einem  modifizierten  Index, 
analog  zum  Ablauf  zur  Arbeitsweise  einer  for-Schleife. 

•  Zeile  9-11 

Hier  wird  die  Funktion  erneut  definiert,  jedoch  in  spezieller  Form.  Damit  die  Rekursion 
aus  Zeile  5  bis  7  terminieren  kann,  wird  ein  Abbruchkriterium  benötigt.  Dies  geschieht, 
indem  die  Funktion  OuterLoop  partiell  spezialisiert  wird  und  für  einen  bestimmten  Fall 

11  VectorT<T>  ist  ein  Template-Container  ähnlich  dem  STL  Vektor,  der  im  Rahmen  dieser  Arbeit  ent- 
wickelt wurde. 

12Diese  Template-Klasse  wurde  ebenfalls  im  Rahmen  dieser  Arbeit  erstellt.  Sie  besitzt  identische 
Funktionen  wie  die  Klasse  VectorT<T>  mit  dem  Unterschied,  dass  die  Vektordimension  zu  Überset- 
zungsphase bekannt  ist. 

13siehe  dazu  in  Listing  5.2  in  Zeile  4 
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ein  Abbruchkriterium  liefert.  Eine  partielle  Spezialisierung  einer  Funktion  kann  ver- 
wendet werden,  um  für  einen  bestimmten  Fall  während  der  Ubersetzungsphase  eine  kon- 
krete Implementierung  anzugeben.  In  diesem  Fall  dient  diese  als  Abbruchkriterium  der 
Rekursion  während  der  Instanziierunsphase:  Falls  der  Schleifenindex  auf  die  maximale 
Anzahl  der  Vektorelemente  ( uiDimension)  hochgezählt  ist,  wird  die  Instanziierunsphase 
abgebrochen,  indem  die  partiell  spezialisierte  Funktion  anstatt  der  Funktion  aus  Zeile 
1-8  aufgerufen  wird. 

Es  könnte  hier  noch  eine  Version  4  geben,  bei  der  die  innere  for-Schleife  analog  zur  Vorge- 
hensweise bei  der  Version  3  während  der  Übersetzungsphase  vereinfacht  werden  könnte.  Dies 
wird  hier  bewusst  nicht  aufgeführt,  da  dies  lediglich  eine  Wiederholung  wäre.  Die  drei  ver- 
schiedenen Version  werden  hinsichtlich  ihrer  Laufzeit  und  den  dabei  benötigten  Taktzyklen  auf 
TP1  untersucht.  Ferner  wird  die  resultierende  Programmgröße  (in  Bytes)  und  die  benötigte  [TP]  Testplattform 
Übersetzungszeit  unter  Verwendung  des  GNU  Compilers  (Version  4.5.1)  bei  der  höchsten  Op- 
timierungsstufe (03)  beurteilt. 


Anzahl  Taktzyklen  Laufzeit  [s] 


■  Version  1      Version  2    «Version  3  «Version  1     Version  2  ■  Version  3 


Übersetzungszeit[s]  Größe  [Byte] 


■  Version  1  «Version  2  «Version  3  ■  Version  1     Version  2  «Version  3 


Abbildung  5.3:  Gegenüberstellung  der  Laufzeit,  Anzahl  der  Taktzyklen,  Compilie- 
rungszeit  und  Größe  von  Template  Metaprogrammen 

Die  Ergebnisse  dieser  Untersuchung  sind  in  Abb.  5.3  dargestellt.  Betrachtet  man  die  Anzahl 
der  eingeforderten  Taktzyklen  und  die  Laufzeit14  der  jeweiligen  Versionen,  so  benötigt  die  Ver- 
sion 2  am  wenigsten  Takte  und  folglich  Laufzeit.  Anscheinend  wirkt  sich  das  loop-unrolling  der 
Version  3  negativ  auf  die  Laufzeit  aus.  Ein  weiteres  Indiz  hierfür  zeigt  ein  Blick  auf  die  Größe15 
der  erzeugten  ausführbaren  Datei.  Hierbei  ist  das  erzeugte  Programm  um  etwa  das  2.5-fache 
der  Version  2  und  um  das  40-fache  der  Version  1  größer.  Auch  die  Übersetzungszeit  des  Pro- 
gramms der  Version  3  schlägt  mit  nahezu  3  Minuten  zu  Buche,  was  etwas  mehr  als  doppelt  so 
lange  dauert  wie  das  Übersetzen  der  Version  2.  Für  diese  Art  der  Aufgabenstellung  scheint  die 
Version  2  am  besten  geeignet,  da  hier  ein  guter  Kompromiss  zwischen  Übersetzungszeit  und 
Laufzeit  gefunden  werden  konnte. 

l4Diese  wurde  mit  dem  Linux  time  Kommando  ermittelt.  Hierbei  wird  auf  die  tatsächlich  benötigte 
Zeitspanne  Bezug  genommen. 

15Zur  Bestimmung  der  jeweiligen  Größe  wurde  das  Linux  size-Kommando  verwendet. 
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1  template  <typename  T,   unsigned   int  N>  void  Square  (VectorTMP<T,N>  &a) 

2  { 


3  VectorTMP<T,N>  v(a); 

4  for ( unsigned    int  n=0;  n  <  N;  n++) 

5  { 

6  for ( unsigned    int    i=0;    i  <=  n;    i ++) 

7  { 

8  a[n]  +=  v[i]   *  v[n— i]; 

9  } 
10  } 


11  } 


Listing  5.2:  Square  Funktion  (Version  2) 


1  template  <typename  T,   unsigned   int  n> 

2  void   OuterLoop  ( VectorTMP<T ,  uiDimension  >  &a 

3  ,   const  VectorTMP<T,  uiDimension  >  &v) 

4  { 

5  for(unsigned    int    i=0;   i  <=  n;    i ++) 

6  a[n]  +=  v[i]   *  v[n— i]; 

7  OuterLoop<T,n  +  l>(a  ,  v)  ; 

8  I 

9  template  <>  void   OuterLoop <long   double,  uiDimension> 

10  (  VectorTMP<long   double  ,  uiDimension>& 

11  ,   const  VectorTMP<long   double  ,  uiDimension  >&){ } 
12 

13  template  <typename  T,   unsigned   int  N> 

14  void   Square  (VectorTMP<T,N>  &a) 

15  { 

16  VectorTMP<T,N>  v(a)  ; 

17  OuterLoop<T,0>(a  ,  v)  ; 

18  } 


Listing  5.3:  Square  Funktion  (Version3) 


5.3.1.2    Vorlagen  zur  C++-Metaprogrammierung 

Besonders  das  Abrollen  von  Schleifen  während  der  Übersetzungsphase  kann  u.U.  die 
Ausführungsgeschwindigkeit  eines  Programms  erhöhen.  Da  TMP  aufgrund  ihrer  an- 
dersartigen Syntax,  verglichen  mit  Standard  C++,  schwerer  lesbar  sind,  werden  im 
Folgenden  für  gängige  Anwendungsfälle  wiederverwendbare  Vorlagen  ausgearbeitet. 
Hierzu  wird  zunächst  mit  einer  for-Schleife  aus  begonnen.  Diese  Version 

der  Schleife  wird  während  der  Laufzeitphase  abgearbeitet,  wobei  die  Index- Variable 
einen  Wertebereich  im  Intervall  [0, 10]  überstreicht16.  Das  Pendant  zu  dieser  Schleife 
ist  in  Listing  5.5  als  Template  Funktion  angegeben.  Eine  weitere  Variante  dieser  for- 
Schleife  kann  auch  als  Klassentemplate  realisiert  werden,  diese  findet  man  im  Anhang 
auf  Seite  227. 


Soll  der  Indexbereich  auch  negative  Zahlen  enthalten,  ist  es  erforderlich,  den  Datentyp  der  Index- 
Variablen  von  unsigned  int  auf  int  zu  ändern. 
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1 

for ( unsigned    int    uilndex  = 

=  0;    uilndex  <=10 

uilndex  +  +  ) 

2 

{    //  Start 

3 

}    //  Ende 

Listing  5.4:  Laufzeit  for-Schleife 


1  template  <unsigned    int   uilndex>  void  For() 

2  { 

3  //  [Index  ,1] 

4  For<uiIndex  —  1  >() ; 

5  //    [  1  ....  ,  Index  ] 

6  I 

7  template  <>  void  For<0>(){} 


Listing  5.5:  TMP  for-Schleife 


Die  for-Schleife  aus  iteriert  beginnend  vom  Wert  0  zum  Wert  10,  wo- 

hingegen die  for-Schleife  aus  Listing  5.5  sowohl  aufwärts  (  0  — >10  )  als  auch  abwärts 
(10  0)  iteriert.  Die  Richtung  hängt  davon  ab,  an  welcher  Stelle  der  Wert  der  Index- 
Variable  verwendet  wird.  Wird  dieser  vor  dem  rekursiven  Aufruf  verwendet  (Zeile  3), 
dann  erfolgt  die  Iteration  abwärts.  Andernfalls  wird  aufwärts  gezählt,  wenn  der  Wert 
der  Index- Variable  nach  dem  rekursiven  Aufruf  (Zeile  4)  abgegriffen  wird  (Zeile  5). 
Wie  schon  im  vorangegangenen  Beispiel  erwähnt,  benötigt  die  Rekursion  eine  Be- 
dingung zur  Terminierung.  In  diesem  Fall  wird  die  rekursive  Instanziierung  gestoppt, 
sobald  der  Schleifenindex  den  Wert  0  erreicht.  Da  die  Rekursion  während  der  Überset- 
zungsphase durchgeführt  wird,  ist  während  der  Schleife  keine  Schleife  mehr  vorhan- 
den. 

Im  nächsten  Schritt  soll  die  for-Schleife  zu  einer  zweifach  geschachtelten  Schleife 
erweitert  werden  und  dafür  ebenfalls  ein  Muster  angegeben  werden.  Die  erweiterte 
for-Schleife  ist  in  angegeben.  Hierbei  ist  zu  beachten,  dass  die  innere  for- 

Schleife  (Zeile  3)  vom  Index  der  äußeren  Schleife  (Zeile  1)  abhängig  ist. 


1  for  ( unsigned    int   uilndexl   =  0;    uilndexl    <=10   ;  uilndexl++) 

2  {    //  Start 

3  for(unsigned    int    uilndex2  =  0;    uilndex2  <=  uilndexl  ;  uilndex2++) 

4  {    //  Start 

5  )   //  End 

6  )   //  End 

Listing  5.6:  Laufzeit  for-Schleife,  zweifach  geschachtelt 
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1 

template  <unsigned   int  uilndex> 

void 

InnerFor () 

2 

{ 

3 

InnerFor<uiIndex  —  1  >() ; 

4 

) 

J 

template  <>  void  InnerFor  <0  >()  { } 

6 

7 
8 

template  <unsigned   int  uilndex> 

void 

For() 

9 

{ 

//   [Index  ,  ...  ,1] 

10 

For<uiIndex  —  1  >() ; 

11 

//   [1  ....  ,  Index] 

12 

InnerFor  <uilndex  >()  ; 

13 

) 

14 

template  <>  void  For<0>(){} 

Listing  5.7:  TMP  for-Schleife,  zweifach  geschachtelt 


Das  Metaprogramm  zur  zweifach  geschachtelten  for-Schleife  ist  in  Listing  5.7 
dargestellt.  Hierbei  ist  es  nötig,  für  jede  Schachtelungsebene  eine  eigene  Funktion  zu 
definieren.  Diese  ist  in  Zeile  1  bis  5  dargestellt  und  wird  in  Zeile  12  aufgerufen.  Die  be- 
reits erwähnte  Abhängigkeit  der  Index- Variablen  wird  hier  durch  einfaches  Einsetzen 
des  Wertes  in  den  Aufruf  der  inneren  Schleife  erreicht  (siehe  Zeile  12).  Auch  hierfür 
gibt  es  eine  weitere  Lösungsvariante  in  Form  von  Klassentemplates,  welche  in  Listing 
G.2  auf  Seite  227  angegeben  ist. 

Eine  n-fach  verschachtelte  for-Schleife  erfordert  somit  n  Funktionsdefinitionen  mit 
eindeutigen  Namenskonventionen.  Aus  diesem  Grund  empfiehlt  es  sich  in  der  Praxis, 
die  inneren  Schleifen  in  einem  eigenen  C++-namespace  zu  kapseln.  Dadurch  können 
schon  im  Vorfeld  diese  möglichen  Mehrdeutigkeiten  vermieden  werden.  In  diesem 
Abschnitt  wurden  lediglich  vorlagen  für  for-Schleifen  erarbeitet.  Andere  Schleifenty- 
pen, wie  beispielsweise  wriiie-Schleifen,  wurden  als  Funktions-  u.  Klassentemplates 
in  analoger  vorgehensweise  entwickelt  und  sind  in  Abschnitt  G.3  auf  Seite  228  zu 
finden.  Weitere  Vorlagen  zu  if-else  und  switch-case -Kontrollstrukturen  sind  auf  den 
Seiten  228  und  229  zu  finden.  Die  hier  erarbeiteten  vorlagen  stellen  ein  Grundgerüst 
dar,  mit  dem  ein  herkömmliches  C++-Programm  in  ein  C++-  Templatemetaprogramm 
umgewandelt  werden  kann. 

5.3. 1.3    Verwendung  von  TMP  zur  Lösung  der  homogenen  Van-der- Pol-Gleichung 

Im  folgenden  Beispiel  soll  die  homogene  Van-der- Pol-Gleichung 17  gelöst  werden  und 
dabei  als  erstes  praktisches  Beispiel  dienen,  die  Eignung  von  Metaprogrammierungs- 
techniken  und  deren  Laufzeitverhalten  für  die  Integration  gewöhnlicher  Differential- 
gleichen zu  beurteilen. 

Beispiel  5.3  für  „Laufzeitvergleich  zwischen  TMP  und  herkömmlicher  Programmierung" 

Die  Van-der-Pol'sche  Gleichung: 

x  =  —  ri(x2  —  l)x  +  x  (5.3.1) 

mit  T]  G  R.  Für  rj  =  0  geht  die  Gleichung  zum  harmonischen  Oszillator  über.  In  den  fol- 
[AW]  Anfangswerte     genden  Simulationen  wurden  diese  AW  und  Startbedingungen  verwendet:  x  =  1,  x  =  0  und 


siehe  mehr  dazu  unter  [Bronstein08]  auf  Seite  900. 
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r\  =  1.8.  Ferner  wurde  die  Bewegung  des  Oszillators  über  1000  Integrationsschritte  mit  einer 
Schrittweite  von  h  =  berechnet,  wobei  der  RK4  und  RK10  -  Integrator  zur  Lösung  Verwen- 
dungfand. Das  Verhalten  der  Van-der-Pol  Gleichung  für  die  hier  definierten  AW  ist  in  Abb.5.4 
dargestellt. 


[RK4]  Runge-Kutta 
4. Ordnung 

[RK10]  Runge-Kutta 
10.  Ordnung 


X 

Abbildung  5.4:  Lösung  der  Van-der-Pol'schen  Gleichung 


Um  herauszufinden,  welche  Auswirkung  TMP-Techniken  auf  das  Laufzeitverhalten  haben,  wur- 
den zwei  verschiedene  Versionen  zur  Lösung  der  Van-Der-Pol ' schen-Gleichung  implementiert. 
Die  beiden  Versionen  unterscheiden  sich  nur  anhand  ihrer  Basiskomponenten.  Bei  der  ersten 
Version  {ohne  TMP)  kommen  Klassenobjekte,  wie  VectorT  zum  Einsatz,  welche  beispielsweise 
ihre  Dimension  zur  Laufzeit  bereitstellen.  Außerdem  werden  hierbei  die  einzelnen  Integrati- 
onsschritte innerhalb  einer  for-Schleife  durchgeführt.  Bei  der  Version  mit  TMP  wurde  die  be- 
nötigte for-Schleife  mit  Hilfe  der  erwähnten  Methode  während  der  Ubersetzungszeit  abgerollt. 
Außerdem  basiert  diese  Version  auf  dem  VectorTMF '-Objekt,  das  seine  Dimension  während 
der  Ubersetzungsphase  dem  Compiler  zur  Verfügung  stellt.  Für  die  Simulationen  kam  TP1  mit  [TP]  Testplattform 
g++-4.51&  zum  Einsatz.  Um  mögliche  Einflüsse  des  Betriebssystems  herauszumitteln,  wurden 
die  jeweiligen  Messungen  mehrfach19  durchgeführt.  Die  Ergebnisse  hierfür  sind  in  Abb.5.5 
dargestellt. 


Es  wurden  folgende  Optimierungsoptionen  verwendet:  -03,-march=nocona,-fno-strict-  aliasing,-ßto 
sechs  Mal  pro  Konfiguration 
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Abbildung  5.5:  Ergebnisse  aus  dem  Laufzeitvergleich  zwischen  TMP  und  herkömm- 
licher Programmierung 


Dementsprechend  wird  schnell  klar,  dass  die  verwendete  TMP-Technik  die  Laufzeit  in  allen 
durchgeführten  Versuchen  erheblich  verkürzt.  Wird  aus  den  jeweils  gemessenen  Laufzeiten  ein 
Mittelwert  gebildet,  so  können  die  verschiedenen  Lösungsvarianten  gegenübergestellt  werden. 
Die  Auswertung  ergibt,  dass  im  Falle  des  RK4-Integrators  die  TMP-Variante  um  etwas  mehr 
als  das  6-fache  und  beim  RKIO-Integrator  um  das  14-fache  schneller  ist,  als  die  Variante  ohne 
TMP. 


5.3.1.4   Anwendung  von  TMP  auf  die  Berechnung  von  Satellitenbahnen 

Im  nächsten  Beispiel  wird  untersucht,  um  welchen  prozentualen  Anteil  die  Laufzeit 
eines  Simulationsprogramms  zur  Berechnung  einer  Satellitenbahn  beschleunigt  wer- 
den kann,  falls  bei  der  Programmierung  Metaprogrammierungstechniken  verwendet 
werden. 


[LAGEOS] 

GEOdynamics 

Satellite 


[EGM]  Earth  Gravity 
Modell 


Beispiel  5.4  für  „Simulation  eines  LAGEOS  Orbits  im  anisotropen  Gravitationsfeld  der  Er- 
de" 

LAser  In  diesem  Beispiel  soll  die  Bahn  des  LAGEOS2a  Satelliten  numerisch  integriert  werden.  Es  wird 
ausschließlich  die  gravitative  Anziehungskraft  der  Erde  berücksichtigt  und  andere  Kräfte,  die 
auf  den  Satelliten  wirken,  werden  vernachlässigt.  Hierfür  wird  das  EGM9621  -Modell  verwen- 
det, mit  dessen  Hilfe  die  Anziehungskraft  auf  den  Satelliten  in  jedem  errechneten  Bahnpunkt 
simuliert  werden  kann.  Dabei  ist  bei  jedem  Aufruf  der  Kraftfunktion  eine  Kugelfunktionsent- 
wicklung eines  bestimmten  Entwicklungsgrades  l  und  einer  bestimmten  Ordnung  m  durch- 
zuführen. Bei  dieser  Rechnung  gilt:  Je  höher  der  Entwicklungsgrad,  bzw.  die  Ordnung  der 
Kugelfunktionsentwicklung,  desto  genauer  kann  die  tatsächlich  auf  den  Satelliten  ausgeübte 
gravitative  Anziehungskraft  der  Erde  auf  den  Satelliten  approximiert  werden.  Für  diese  Si- 
mulationen werden  verschiedene  Entwicklungsgrade  im  Intervall  gewählt  (mit  l,  m  €  [4,  50]), 
um  den  zeitlichen  Berechnungsaufwand  in  Abhängigkeit  dieser  Parameter  sichtbar  zu  machen. 
Die  Kugelfunktionsentwicklung  wird  programmiertechnisch  mit  for-Schleifen  realisiert,  was 
den  Einsatz  der  TMP -Techniken  begünstigt. 


Mehr  Information  zur  LAGEOS-Mission  ist  auf  der  Webseite  des  Projekts   zu  finden: 
http://ilrs.gsfc.nasa.gov/satellite_missions/list_of_satellites/lagl_general.html 
21  Siehe  mehr  dazu  unter  [EGM96] 
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Ferner  wurde  die  Bahnkonfiguration  so  gewählt,  dass  sie  möglichst  genau  mit  der  tatsächlichen 
Bahn  des  LAGEOS-1  Satelliten  übereinstimmt.  Dieser  benötigt  im  Mittel  225  Minuten  pro  Um- 
lauf (6,4  Umläufe  pro  Tag)  mit  5860  Kilometer  Perigäumsdistanz.  Für  diese  Simulation  wird 
ein  Integrationszeitraum  von  einer  Woche  gewählt,  was  44,8  Umläufen  entspricht.  Zum  Lauf- 
zeittest wurde  die  TP1  mit  g++-4.522  eingesetzt.  Ferner  wurde  der  long  double-Datentyp  der  [TP]  Testplattform 
C- Standardbibliothek  zur  Berechnung  ausgewählt.  Um  die  Größe  des  übersetzten  Programms 
zu  verringern  wurde  das  Hilfsprogramm  Strip23  verwendet.  Dieses  Hilfsprogramm  entfernt  aus 
dem  kompilierten  Programm  unnötige  Symbole,  wodurch  die  Größe  reduziert  wird.  Zur  Bestim- 
mung der  Größe  des  ausführbaren  Programms  wurde  das  Linux  Programm  size24  verwendet. 
Dieses  gibt  sowohl  die  Anzahl  der  tatsächlich  von  der  CPU  benötigten  Bytes  als  auch  die  Grö-  [CPU]  Central 
ße  des  statisch  vorhanden  Daten  (ebenfalls  in  Byte)  an.  Processing  Unit 

In  Abb.  5.6  sind  die  gemessenen  Laufzeiten  in  Abhängigkeit  des  Entwicklungsgrades  (l  =  m) 
für  die  Berechnungsvarianten  mit  und  ohne  TMP -Techniken  angegeben.  Wie  ersichtlich  wird, 
benötigt  die  Berechnung  mit  TMP  bei  allen  Simulationen  deutlich  weniger  Laufzeit  als  die 
herkömmliche  Methode  ohne  TMP.  Die  hierbei  erzielte  Verbesserung  liegt,  je  nach  Grad  und 
Ordnung,  im  Bereich  von  10  bis  40  Prozent.  Hier  soll  noch  auf  den  Anstieg  der  Programmgrö- 
ße bei  der  Verwendung  von  TMP-Techniken  hingewiesen  werden  (siehe  Abb.  5.6  kleines  Dia- 
gramm25). Der  Grund  hierfür  liegt  am  erzwungenen  Abrollen  der  jeweiligen  for-Schleifen  und 
dem  damit  verbundenen  Aufblähen  des  Quellcodes.  Werden  zu  viele  dieser  Vereinfachungen 
durchgeführt,  so  steigt  die  Programmgröße  u.U.  derart  stark  an,  dass  sich  dies  negativ  auf  die 
Laufzeit  auswirkt.  Es  ist  somit  die  Balance  zwischen  rekursiver  Instanziierung  und  Programm- 
größe zu  halten,  um  ein  Optimum  an  Ablaufgeschwindigkeit  zu  erzielen.  Der  Anstieg  bei  der 
Rechnung  mit  TMP-Techniken  beim  Entwicklungsgrad  von  19  konnte  auch  durch  mehrfaches 
Wiederholen  der  Simulation  nicht  nachgestellt  werden  und  scheint  somit  durch  das  Scheduling 
des  Betriebssystems  verursacht  worden  zu  sein. 


Dabei  wurden  folgende  Optimierungseinstellungen  verwendet:  -ftempIate-depth-60580  -03  - 
march=nocona. 

23 siehe  mehr  dazu  unter  folgendem  Weblink:  http://linux.die. net/man/l/strip  oder  auf  der  Linux  man- 
page. 

24siehe  mehr  dazu  unter  folgendem  Weblink:  http://manpages.ubuntu.com/manpages/gutsy/manl/avr- 
size.l.html 

25Hier  wurden  die  tatsächlich  von  der  CPU  benötigten  Bytes  verwendet.  Diese  wurden  mit  dem  Linux 
Programm  size  ermittelt. 
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Abbildung  5.6:  Ergebnisse  der  Laufzeitmessungen  eines  Programms  zur  Simulation 
eines  LAGEOS  Orbits  in  Abhängigkeit  von  Grad  und  Ordnung 

Außerdem  gibt  es  erhebliche  Unterschiede  in  den  benötigten  Ubersetzungszeiten.  Die  Varian- 
te mit  TMP  benötigte  im  Mittel  2.5  Minuten,  bis  das  Programm  kompiliert  war,  wohingegen 
die  Variante  ohne  TMP  im  Mittel  1  Sekunde  zum  Ubersetzen  benötigte.  Diese  langen  Uberset- 
zungszeiten sind  ein  entscheidender  Nachteil  der  TMP-Techniken  und  können  beispielsweise 
verringert  werden,  indem  auf  einer  leistungsfähigeren  Maschine  übersetzt  wird.  Zudem  zeigten 
Experimente  mit  anderen  Compilern,  dass  der  clang-Compiler26  bei  dieser  Aufgabenstellung 
im  Mittel  bis  zu  einer  Minute  Ubersetzungszeit  einsparen  konnte. 

5.3.1.5    Anwendung  von  TMP  zur  Berechnung  trigonometrischer  Funktionen 

Eine  weitere  mögliche  Anwendung  für  TMP-Techniken  ist  die  Implementierung  trigo- 
nometrischer Funktionen.  Da  trigonometrische  Funktionen  als  Reihe  dargestellt  wer- 
den können  und  diese  iterativ  lösbar  sind,  kann  hierfür  auf  die  bereits  erarbeiteten  Me- 
thoden der  TMP-Techniken  zurückgegriffen  werden.  Somit  können  die  Standardfunk- 
tionen, wie  sin,  cos,tan,atan, ...  als  C++-Templatemetaprogramme  implementiert 
werden.  In  folgender  Berechnung  wird  das  Prinzip  am  Beispiel  der  Sinus-Funktion 
(sin)  aufgezeigt.  Anschließend  wird  das  Laufzeitverhalten  der  Standardbibliothek  ge- 
genübergestellt und  beurteilt. 

Beispiel  5.5  für  „Implementierung  der  Sinus  Funktion  als  C++-Templatemetaprogramm" 

Die  Sinus-Funktion  soll  in  einer  Reihe  entwickelt  und  die  ersten  fünf  Reihentenne,  in  Abhän- 


Hierbei  wurde  die  Version  2.8  der  Compilersuite  verwendet.  Siehe  mehr  dazu  unter 
[CLangCompiler] 
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gigkeit  des  Parameters  t,  können  wie  folgt  geschrieben  werden21 : 


5040 


1 


362880 


1 


t9-... 


(5.3.2) 


^=*-3!  +  5!-7!  +  9! 


t3     t5     t7  t9 


Soll  nun  ein  Funktionswert  an  der  Stelle  t  mit  Hilfe  eines  Templatemetaprogramms  berechnet 
werden,  so  sind  hierfür  Hilfsfunktionen  zur  Berechnung  der  Potenz  und  Fakultät  erforderlich. 
Erstere  berechnet  aus  einer  gegebenen  Gleitkommazahl  (x)  und  einer  angegebenen  Hochzahl 
(i)  die  Potenz  (x%).  Dies  ist  ebenfalls  eine  TMP -Funktion,  worin  die  erforderliche  Iteration 
während  der  Ubersetzungsphase  durchgeführt  wird.  Lediglich  die  Berechnung  der  Gleitkom- 
mazahlen werden  hier  während  der  Laufzeitphase  durchgeführt.  Die  zweite  Hilfsfunktion  be- 
rechnet die  Fakultät  einer  gegebenen  Integerzahl.  Diese  wird  vollständig  während  der  Überset- 
zungsphase berechnet,  sodass  dadurch  keine  Laufzeit  in  Anspruch  genommen  wird.  Die  beiden 
Hilfsprogramme  sind  in  den  Listings  G.9  und  G.10  auf  Seite  230  angegeben.  Das  Programm 
zur  Berechnung  des  Sinus  ist  in  Listing  5.8  angegeben.  Dies  soll  im  Folgenden  detailliert  er- 
klärt werden: 


Enthält  die  Funktionsdefinition  mit  zwei  Template-Parametern.  Hierbei  ist  T  ein  Platz- 
halter für  den  Typ  der  Gleitkommazahl  und  N  ein  Platzhalter  für  die  Ordnung  der  Rei- 
henentwicklung. Der  Funktionsparameter  x  ist  ein  Platzhalter  für  den  Abszissenwert. 
Soll  beispielsweise  der  Sinus  an  der  Stelle  x  —  0.1  unter  Verwendung  des  T  —  double- 
Datentyps  mit  einer  Ordnung  N  =  20  entwickelt  werden,  so  würde  der  Aufruf  wie  folgt 
lauten:  Sin<double,20>(0.1); 

•  Zeilen  3  bis  6: 

In  dieser  und  den  weiteren  Zeilen  wird  der  Bedingungsoperator  ?  verwendet2*1.  Wie  in 
Gleichung  5.3.2  dargestellt,  enthält  die  Reihenentwicklung  eines  Sinus  ausschließlich 
ungerade  Indices.  Um  dies  zu  gewährleisten,  wird  in  der  ersten  Bedingung  ermittelt, 
ob  die  Variable  N  einen  geraden  oder  ungeraden  Wert  besitzt.  Ist  der  Wert  gerade, 
so  wird  der  Index  um  eins  reduziert  und  die  Funktion  wird  erneut  rekursiv  aufgerufen. 
Falls  der  Wert  ungerade  ist,  wird  ebenfalls  die  Funktion  rekursiv  aufgerufen  (Zeile  4). 
Hierbei  wird  der  Index  bei  jedem  Aufruf  der  Rekursion  um  zwei  reduziert,  solange  bis 
die  Rekursion  terminiert  (Zeile  10).  In  den  Zeilen  5  und  6  werden  die  bereits  erwähnten 
Hilfsfunktionen,  mit  dem  jeweiligen  Wert  der  Variablen  N,  aufgerufen,  wobei  vorher  in 
Abhängigkeit  des  Wertes  von  N  das  Vorzeichen  gesetzt  wird. 

•  Zeilen  8  bis  12: 

In  den  Zeilen  8  bis  10  ist  ein  Präprozessor-Makro  definiert.  Dieses  wird  in  Zeile  12 
aufgerufen  und  stellt  das  Kriterium  der  rekursiven  Schleife  dar  (Zeile  10).  In  Zeile  9 
wird  zudem  ein  Sonderfall  behandelt:  Falls  die  Reihenentwicklung  des  Sinus  mit  der 
Ordnung  1  aufgerufen  wird,  dann  wird  der  Abszissenwert  zurückgegeben. 


siehe  mehr  dazu  [Bronstein08] 
28Dieser  Operator  entstammt  der  Programmiersprache  C  und  kann  als  verkürzte  Schreibweise  einer 
if-eJse-Bedingung  angesehen  werden.  Dessen  Funktionsweise  ist  in  [Kernighan90]  in  Abschnitt  2.11 
erklärt. 


•  Zeile  1: 
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1  template  <typename  T,unsigned   int  N>  inline  T  Sin(const  T  &x) 

2  { 

3  return   (!(N%2))  ?  Sin <T  ,  (  !  (N%2))  ?N-  1 :0>(x ) 

4  :    Sin<T,(N%2)?N-2:0>(x)  + 

5  ((((N-l)/2)%2)?-l:l)*Pow<(N%2)?N:0  ,T>(x) 

6  /Fact  <(N%2)?N:0  ,T>()  ; 

7  j 

8  #define  TERMINATE_SIN_LOOP ( TYPE )  \ 

9  templateo  inline  TYPE  Sin  <TYPE,  1  >(  const  TYPE  &x  ){  return  x  ;}\ 
10  templateo  inline  TYPE  Sin  <TYPE,0  >(  const  TYPE  &    ){  return  0.0;) 
11 

1 2  TERMINATE_SIN_LOOP  (double) 


Listing  5.8:  TMP  Sinus 


Nach  Vorgabe  des  oben  durchgeführten  Beispiels  wurden  einige  trigonometrische 
Funktionen  der  C-Standardbibliothek  als  Templatemetaprogramme  implementiert.  Um 
deren  Leistungsfähigkeit  hinsichtlich  numerischer  Stabilität  und  Ablaufgeschwindig- 
keit beurteilen  zu  können,  werden  diese  einem  Leistungstest  (Benchmark)  unterzogen. 
Hierbei  wird  das  Programm  fbench29  verwendet.  Dieses  wurde  ursprünglich  zur  Lei- 
stungsmessung und  Verifikation30  trigonometrischer  Funktionen  der  C-Standardbibliothek 
verwendet  und  für  diesen  Zweck  umgeschrieben,  sodass  auch  C++  Programme  über- 
prüft werden  können.  Damit  ist  es  nun  möglich,  die  trigonometrischen  Funktionen, 
welche  auf  der  TMP-Technik  basieren,  auf  ihre  Korrektheit  hin  zu  überprüfen.  Außer- 
dem kann  ein  Laufzeitvergleich  mit  den  Routinen  der  C-Standardbibliothek  durchge- 
führt werden31 .  Die  Ergebnisse  der  Laufzeitmessungen  sind  in  Abb  5.7  dargestellt.  Um 
mögliche  Beeinflussungen  durch  des  Betriebssystem  herauszumitteln,  wurde  pro  Kon- 
[TP]  Testplattform  figuration  jeder  Benchmark  fünfmal  durchgeführt  (auf  TP1).  Außerdem  wurden  zwei 
verschiedene  Compiler  verwendet:  der  GNU  C++-Compiler  (g++32)  und  der  Clang- 
Compiler  (clang++33). 


Dies  ist  ein  Programm  zur  Verifikation  und  Leistungsmessung  trigonometrischer  C-Funktionen.  Sie- 
he mehr  dazu  unter  [fbench]. 

30Hierfür  wird  ein  ray  tracing  -  Algorithmus  verwendet.  Dieser  basiert  fast  ausschließlich  auf  trigono- 
metrischen Transformationen.  Mehr  Informationen  zum  ray  tracing-Algorithmen  können  in  [Shirley07] 
nachgeschlagen  werden. 

31Das  Benchmarkprogramm  wurde  dabei  wie  folgt  aufgerufen:  time  ./fbench  10000000 

32 Version  4.5.1 

33Version  2.8 
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Aus  den  Laufzeitmessungen  wird  ersichtlich,  dass  die  erzielten  Laufzeiten  sehr 
stark  vom  verwendeten  Compiler  und  dessen  Optimierung  während  des  Übersetzungs- 
vorgangs abhängig  sind.  Bei  allen  fünf  Versuchen,  sowohl  bei  TMP-Funktionen,  als 
auch  bei  den  Funktionen  der  C-Standardbibliothek,  erzeugte  der  Clang-Compiler  ef- 
fizientere Programme.  Außerdem  war  bei  keinem  der  Versuche  die  TMP- Variante 
schneller  als  die  der  Standardbibliothek  und  stellt  somit  keinen  effizienteren  Ersatz 
zu  den  Standardbibliotheksfunktionen  dar.  Dennoch  konnte  gezeigt  werden,  dass  die 
TMP-Technik  prinzipiell  geeignet  ist,  derartige  Problemstellungen  zu  lösen.  Außer- 
dem deutet  der  auffällige  Laufzeitunterschied  zwischen  g++  und  clang++  darauf  hin, 
dass  durch  weitere  Verbesserung  der  Compilersuiten  und  insbesondere  der  darin  ver- 
wendeten Optimierungsroutinen  ein  C++-Templatemetaprogramm  die  Geschwindig- 
keit einer  Routine  der  Standardbibliothek  erreichen  kann.  Darüber  hinaus  wäre  es  in- 
teressant, welche  Laufzeitunterschiede  sich  bei  sonst  identischer  Hardware,  aber  un- 
terschiedlicher Prozessorarchitektur  (32/64-Bit),  ergeben  würden. 


5.3.1.6    Bewertung  von  TMP-Techniken 

Soll  bei  einem  Programm  TMP  zum  Einsatz  kommen,  dann  sollten  folgende  Gesichts- 
punkte bedacht  werden: 

•  Verhältnis  zwischen  Übersetzungszeit  und  Ausführungszeit 

Da  Templatemetaprogramme  während  der  Instanziierunsphase  von  Templates 
verarbeitet  werden,  steigt  der  zeitliche  Aufwand  u.U.  enorm.  Dabei  ist  jedoch 
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nicht  immer  sichergestellt,  dass  das  erstellte  Programm  an  Ausführungsgeschwin- 
digkeit zulegt,  wie  einige  der  behandelten  Beispiele34  gezeigt  haben.  Folglich  ist 
es  wichtig,  die  Balance  zwischen  Übersetzungs-  u.  Ausführungszeit  zu  finden, 
da  zu  exzessives  Anwenden  dieser  Technik  zu  nicht  praktikablen  Übersetzungs- 
zeiten führt. 

•  Anwachsen  der  Programmgröße 

Durch  massiven  Einsatz  rekursiver  Vereinfachung  von  for-Schleifen  kann  die 
Programmgröße  derart  ansteigen,  dass  sich  dies  negativ  auf  die  Ausführungsge- 
schwindigkeit auswirkt.  Es  ist  somit  ein  Mittelweg  zwischen  rekursiver  Template- 
Instanziierung  und  Programmgröße  anzustreben,  um  ein  Optimum  an  Ausfüh- 
rungsgeschwindigkeit zu  erreichen. 

•  Lesbarkeit  und  Wartbarkeit 

Die  Syntax  von  Templatemetaprogrammen  ist  durch  ihre  rekursive  Struktur  an- 
fangs gewöhnungsbedürftig  und  erfordert  einiges  an  Erfahrung.  Dies  wirkt  sich 
nachteilig  auf  die  Wartbarkeit  des  erstellten  Quellcodes  aus. 

•  Portabilität 

Da  ein  Templatemetaprogramm  ausschließlich  vom  Compiler  verarbeitet  wird, 
ist  es  folglich  auch  von  dessen  interner  Implementierung  abhängig.  Somit  ist 
weder  gewährleistet,  dass  jeder  Compiler  bzw.  Version  des  Compilers  ein  Tem- 
platemetaprogramm verarbeiten  kann.  Hinzu  kommen  noch  plattformbezoge- 
ne Eigenheiten  der  jeweiligen  Compiler,  welche  eine  Portierung  zusätzlich  er- 
schweren können. 

•  Auffinden  von  Fehlern 

Das  Auffinden  von  Fehlern  während  der  Entwicklungsphase  wird  hier  beson- 
ders erschwert.  Dabei  kann  es  beispielsweise  bei  einem  syntaktisch  falschen 
Programm  vorkommen,  dass  der  Compiler  hunderte  von  Seiten  Fehlermeldun- 
gen produziert,  ohne  auf  das  tatsächliche  Problem  hinzuweisen.  Ferner  gibt  es 
keine  Programme  zur  Analyse  von  Templatemetaprogrammen.  Die  Entwicklung 
derartiger  Programme  wird  zusätzlich  erschwert,  da  es  nicht  möglich  ist,  an  be- 
stimmten Programmstellen  Zwischenwerte  auszugeben. 


5.3.1.7    Fazit  und  weiterführende  Literatur 

Die  Verwendung  von  C++-Templatemetaprogrammierung  kann  zu  signifikanten  Ge- 
schwindigkeitsvorteilen führen,  es  darf  jedoch  die  benötigte  Einarbeitungszeit  und  der 
nötige  Aufwand  während  der  Entwicklungsphase  nicht  unterschätzt  werden.  Des  Wei- 
teren kann  das  Buch  von  [Stroustrup04]  empfohlen  werden.  Darin  wird  das  Konzept 
[mpl]  Boost  der  Templatemetaprogrammierung  vorgestellt  und  auf  die  Funktionsweise  der  MPL35 

Metaprogrammmg      eingegangen.  Ferner  bietet  das  Buch  von  [Vandevoorde08]  eine  gute  Hilfestellung  zur 

Library 

Einarbeitung  in  dieses  Thema.  Darin  wird  u.a.  ein  allgemeiner  Uberblick  zur  Template- 
programmierung, als  auch  zur  Templatemetaprogrammierung  geboten.  Ergänzend  soll 


siehe  mehr  dazu  auf  Seite  107 
siehe  mehr  dazu  unter  [MPL] 
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hier  noch  auf  das  blitz++  -Projekt  hingewiesen  werden.  Hierbei  handelt  es  sich  um 
eine  C++-Bibliothek,  in  der  Metaprogrammierungstechniken  eingesetzt  wurden,  um 
auf  Geschwindigkeit  hin  optimierte  mathematische  Operationen  zu  realisieren.  Dabei 
werden  so  genannte  expression -Templates  eingesetzt.  Dies  ist  eine  Metaprogrammie- 
rungstechnik,  bei  der  durch  massive  Überladung  von  Operatoren  die  Vereinfachung 
von  mathematischen  Ausdrücken  in  die  Übersetzungsphase  verlagert,  d.h.  dem  Com- 
piler überlassen  wird.  Außerdem  ist  das  Buch  von  [AlexandrescuOl]  erwähnenswert. 
Dort  werden  Design-Pattern  zur  Lösung  von  Standardproblemen  der  Informatik  ange- 
geben. Diese  werden  mit  Hilfe  von  TMP-Techniken  gelöst,  detailliert  erläutert  und  mit 
prägnanten  Beispielen  untermauert. 


5.3.2    Konzepte  der  parallelen  Programmierung 

Der  derzeitige  Trend,  immer  mehr  Prozessorkerne  in  einen  Computerchip  zu  integrie- 
ren kann  u.U.  eine  erhebliche  Leistungsverbesserung  für  bestimmte  Anwendungsfälle 
bedeuten.  Ganz  im  Gegenteil  zu  früheren  Chipverbesserungen,  wie  die  Erhöhung  des 
Prozessortaktes,  hat  diese  Änderung  einen  Einfluss  auf  die  Softwareentwicklung  und 
deren  Methoden.  Hierbei  kann  prinzipiell  von  zwei  verschiedenen  Voraussetzungen 
ausgegangen  werden.  Wird  der  Speicher,  welcher  während  einer  parallelen  Abarbei- 
tungssequenz benötigt  wird,  von  mehreren  parallelen  Ablauffäden  geteilt,  so  spricht 
man  i.A.  von  einer  shared  memory-Architektur.  Besitzt  andererseits  jeder  parallele 
Ablauffaden  seinen  eigenen  Speicherbereich,  welcher  unabhängig  vom  anderen  Spei- 
cher ist,  so  wird  dies  als  distributed  memory-Architektur  bezeichnet.  Dies  ist  beispiels- 
weise der  Fall,  falls  mehrere  Computer  mit  Hilfe  eines  Computernetzwerks  zu  einem 
Rechnerverbund  zusammengeschaltet  werden,  um  eine  bestimmte  Aufgabe  zu  lösen. 
Diese  beiden  Architekturen  sind  in  Abb.  5.8  illustriert. 
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Abbildung  5.8:  Konzepte  paralleler  Architekturen 


Auf  der  linken  Seite  ist  schematisch  eine  shared  memory-Architektur  abgebildet, 
bei  der  sich  mehrere  CPUs  einen  gemeinsamen  Speicher  teilen.  Auf  der  rechten  Seite  [CPU]  Central 

  Processing  Unit 

36  siehe  mehr  dazu  unter  [blitz++] 
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ist  eine  distributed  memory- Architektur  dargestellt.  Hiermit  können  parallele  Aufga- 
ben über  ein  Netzwerk  verteilt  werden.  Demzufolge  besitzt  jeder  Knoten  eine  oder 
mehrere  CPUs  und  einen  abgeschlossenen  Speicher.  Ein  Scheduler  ist  dafür  verant- 
wortlich, die  Aufgaben  an  die  jeweiligen  Knoten  zu  verteilen.  Aus  diesem  Grund  wer- 
den derartige  Architekturen  in  der  Literatur  oft  als  verteilte  Systeme37  bezeichnet. 


5.3.2.1    Shared  Memory  Parallelisierung  [SMP]  mit  OpenMP 

[OpenMP]  Open  OpenMP  ist  eine  Programmierschnittstelle,  mit  welcher  ein  Programm  oder  bestimm- 
Muiti-Processmg  te  pr0grammteile  nach  dem  shared  memory-Prinzip  parallelisiert  werden  können.  Um 
einen  bestehenden  Programmteil  zu  parallelisieren,  wird  zu  Beginn  eine  Pragma  Di- 
rektive38 geschrieben.  Somit  ist  dem  Compiler  bekannt  gegeben,  dass  an  dieser  Stelle 
ein  Bereich  beginnt,  der  parallelisiert  werden  kann.  Das  Arbeitsprinzip  von  OpenMP 
ist  in  Abb.  5.9  dargestellt. 


master  thread 


#pragma  omp  parallel 
{ 


master  thread    thread  1    thread  2      thread  n 


fork 


join 


master  thread 


Abbildung  5.9:  Das  Arbeitsprinzip  von  OpenMP 


Die  parallele  Ausführung  eines  Programmteils  mit  OpenMP  wird  mit  Hilfe  von 
threads39  realisiert.  Zu  Beginn  eines  jeden  OpenMP  Programms  wird  ein  thread,  der 
master  thread,  aktiviert  und  kann  als  Hauptablauffaden  betrachtet  werden.  Wird  nun 
während  der  Ausführung  eine  Pragma  Direktive  verwendet  (z.B.  #pragma  omp  prallel), 
so  erzwingt  dies  eine  Aufteilung  in  mehrere  parallele  Ablauffäden  (threads).  Dieser 
Vorgang  wird  i.A.  als  fork  bezeichnet.  Diese  parallelen  threads  teilen  sich  die  nötige 
Arbeit,  was  u.U.  mit  einem  erheblichen  Leistungszuwachs  verbunden  sein  kann.  Ha- 
ben alle  threads  ihre  Arbeit  erledigt,  dann  werden  die  parallelen  threads  terminiert  und 
vorher  die  Ergebnisse  vom  master  thread  eingesammelt.  Diese  Vorgang  wird  als 
bezeichnet. 

37  Mehr  zum  Thema  der  verteilten  Systeme  und  den  damit  verbundenen  Algorithmen  findet  man  in 
[Ajay08] 

38Eine  Pragma-Direktive  weist  den  Compiler  an,  die  durch  die  Pragma  Direktive  bezeichnete  und 
meist  von  der  Implementierung  des  Compilers  abhängige  Operation  durchzuführen.  Ist  diese  Direktive 
dem  Compiler  nicht  bekannt,  dann  wird  diese  ignoriert.  Pragma-Direktiven  sind  im  ANSI-C-Standard 
definiert.  Dieser  kann  unter  http://www.open-std.org/jtcl/sc22/wgl4/www/standards  eingesehen  werden. 

39  Threads  können  als  parallele  Ablauffäden  innerhalb  eines  Prozesses  aufgefasst  werden. 
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Beispiel  5.6  „Simulation  eines  LAGEOS  Orbits  im  anisotropen  Gravitationsfeld  der  Erde 
mit  Hilfe  von  OpenMP" 

Um  die  Einsatzfähigkeit  von  OpenMP  für  die  Integration  einer  Satellitenbahn  zu  demonstrie- 
ren, soll  das  Beispiel  aus  Seite  114  wieder  aufgegriffen  werden.  Hierfür  wurden  bei  der  Be- 
rechnung der  Beschleunigung  -  im  Quellcode  der  Kraftfunktion  -  welche  durch  das  Gravita- 
tionsfeld der  Erde  auf  den  Satelliten  ausgeübt  wird,  OpenMP -Direktiven  angebracht.  Dabei 
wurden  die  Berechnungen  in  unabhängige  Teile  zerlegt,  sodass  diese  Teile  parallel  verarbei- 
tet werden  können.  Dies  wurde  für  beide  Varianten  des  vorausgegangenen  Beispiels,  mit  und 
ohne  TMP-Technik,  durchgeführt.  Alle  anderen  Randbedingungen  wurden  belassen,  um  mög- 
lichst vergleichbare  Resultate  zu  erzielen.  Die  Ergebnisse  der  Laufzeitmessungen  sind  in  Abb. 
5.10  dargestellt.  Bei  höheren  Entwicklungsgraden  ist  die  Variante  mit  OpenMP  und  diejenigen, 
bei  denen  TMP -Techniken  zum  Einsatz  kamen  am  schnellsten.  Bei  niedrigeren  Entwicklungs- 
graden weist  die  Variante  mit  OpenMP  etwas  langsamere  Laufzeiten  auf.  Dies  liegt  daran,  dass 
hier,  sobald  eine  parallele  Abarbeitung  nach  dem  for-join- Prinzip  beginnt,  zusätzlich  Laufzeit 
verbraucht  wird.  Dies  zeigt,  dass  sich  der  Einsatz  von  OpenMP  erst  ab  einem  gewissen  Auf- 
wand lohnt.  Vergleicht  man  die  beiden  Varianten,  ohne  Einsatz  von  TMP  und  ohne  OpenMP 
mit  dem  Einsatz  von  TMP  und  mit  OpenMP,  so  kann  durch  letztere  Variante  im  Mittel  33,6% 
Laufzeit  eingespart  werden,  was  durchaus  lohnenswert  erscheint. 


Abbildung  5.10:  Ergebnisse  der  Laufzeitmessungen  bei  Verwendung  von  TMP- 
Techniken  und  OpenMP 


124 


Kapitel  5:  Methoden  zur  Laufzeitverbesserung  von  Programmen 


5.3.2.2    Fazit  und  weiterführende  Literatur 


In  der  durchgeführten  Beispielsimulation  konnte  die  Methode  der  Parallelisierung  mit 
OpenMP  zwar  überzeugen,  es  ist  aber  dennoch  Vorsicht  geboten,  da  bei  der  Program- 
mierung darauf  geachtet  werden  muss,  so  genannte  race  conditions  zu  vermeiden. 
Aus  diesem  Grund  ist  es  empfehlenswert,  das  Programm  schon  während  der  Ent- 
wicklungsphase ohne  OpenMP  zu  verifizieren.  Diese  und  andere  Fallstricke  im  Be- 
reich der  parallelen  Programmierung  können  schon  während  der  Entwicklungsphase 
erkannt  werden.  Hierzu  können  Hilfsprogramme  wie  der  Intel®Inspector  XE41,  als 
auch  Cppcheck42  oder  Polyspace43  verwendet  werden.  Die  hier  gezeigte  Methode  der 
Parallelverarbeitung  ist  nicht  die  einzige.  Es  gibt  weitere  Möglichkeiten,  ein  seriel- 
les Programm  zur  Parallelverarbeitung  umzuschreiben44.  Eine  weitere,  derzeit  häufig 
[OpenMPi]  Open  genutzte  Variante  ist  OpenMPI45.  Hierbei  handelt  es  sich  um  eine  Infrastruktur  zu 
Message      Passmg  Realisierung  eines  verteilten  Systems  (distributed  memory-Architektur).  Eine  MPI- 

liitcri3.cc 

Anwendung  ist  i.d.R.  in  mehrere  Prozesse  aufgeteilt,  welche  dann  miteinander  kom- 
munizieren. Diese  hat  den  Vorteil,  dass  sie  auch  über  Rechnergrenzen  hinweg  realisiert 
werden  kann.  Dieser  Ansatz  wurde  hier  nicht  weiter  verfolgt,  da  sonst  der  Rahmen  die- 
ser Arbeit  gesprengt  werden  würde. 

Zur  Programmierung  mit  OpenMP  wird  auf  die  Bücher  von  [Hoffmann08] ,  [Chapman07], 
[Quinn04]  und  [Hughes03]  hingewiesen.  Darüber  hinaus  gibt  es  einige  Ansätze,  die 
Parallelisierung  weitestgehend  in  die  Übersetzungsphase  zu  verlagern.  Ein  nennens- 
[ISPC]  intei®sPMD  wertes  Projekt  ist  der  ISPC-Compiler46,  welcher  Programme  in  C-ähnlicher  Syntax 
Programm  Compiler  übersetzen  kann.  Hierbei  wird  dem  Programmierer  die  Verantwortung  abgenommen, 
ein  Programm  an  bestimmten  Stellen  gezielt  zu  parallelisieren.  Ein  entscheidender 
Nachteil  ist  die  bereits  erwähnte  C-ähnliche  Syntax,  bei  der  gewisse  Sprachmittel  wie 
beispielsweise  switcij-case-Bedingungen  gänzlich  fehlen.  Dennoch  ist  dieser  Ansatz 
zukunftsweisend  und  sollte  von  den  Entwicklern  von  Compilern  berücksichtigt  wer- 
den. Hierbei  wäre  es  wünschenswert,  wenn  derartige  Funktionalitäten  beispielsweise 
in  den  GNU-Compiler  integriert  würden.  Somit  könnten  ältere  Programme,  die  ur- 
sprünglich für  serielle  Verarbeitung  programmiert  wurden,  auch  von  Mehrkernprozes- 
soren profitieren.  Außerdem  zu  erwähnen  ist  der  relativ  neue  Standard  für  paralle- 
le Programmierung  OpenACC47.  Dieser  stellt  eine  Weiterentwicklung  des  OpenMP- 


Dies  sind  Programmkonstrukte,  in  denen  das  Ergebnis  einer  Operation  vom  zeitlichen  Verhalten 
bestimmter  Einzeloperationen  abhängig  ist. 

41siehe  mehr  dazu  unter  http://software.intel.com/en-us/articles/intelinspectorxe/ 

42Dies  ist  ein  statisches  Quellcodeanalyseprogramm  mit  dem  u.a.  deadlocks  identifiziert  werden  kön- 
nen. Mehr  Informationen  können  unter  http://cppcheck.sourceforge.net/  nachgeschlagen  werden. 

43Dies  ist  ein  proprietäres  und  sehr  umfangreiches  Programm,  welches  neben  vielen  anderen  Quellco- 
deanalysen auch  race-conditions  im  Quelltext  aufspüren  kann. 

44  siehe  mehr  zu  alternativen  Ansätzen  der  Parallel  Verarbeitung  mit  C++  unter  [Rauber08],  ab  Seite 
145. 

45Der  OpenMPI  Standard  kann  unter  folgender  Webadresse  eingesehen  werden  http://www.open- 
mpi.org/doc/ 

46  siehe  mehr  dazu  unter  [ISPC-Compiler] 

47 siehe  mehr  dazu  auf  der  Webseite  des  Projekts:  http://www.openacc-standard.org/home,  Download 
15.11.2011 
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Standards  für  PGI  ,  CAPS  und  Cray  CCE  Compilersystemen  dar,  welcher  kom- 
patibel mit  den  gängigen  CPU/GPU-Standards  sein  soll.  Hierzu  werden  während  der  [GPU]  Graphics 
Übersetzungsphase  durch  den  Compiler  Programmstellen  identifiziert,  welche  paral-  Processmg  Hmt 
lelisiert  werden  können.  Diese  Programmstellen  werden  anschließend  dem  Program- 
mierer bekannt  gegeben.  Daraufhin  kann  der  Programmierer  Schritt  für  Schritt  einer 
automatischen  Parallelisierung  zustimmen  oder  diese  an  bestimmten  Stellen  verbieten. 
Ob  der  jeweilige  Programmteil  auf  der  Grafikkarte  oder  der  CPU  ausgeführt  wird,  ent- 
scheidet in  diesem  Fall  der  OpenACC-Compiler.  Erste  Umsetzungen  dieses  Standards 
werden  bis  Mitte  des  Jahres  2012  erwartet. 


5.4    Optimierung  während  der  Übersetzungsphase 

Dieser  Abschnitt  ist  der  Übersetzungsphase  gewidmet,  in  der  Programme  mit  Hilfe 
eines  Compilers  in  die  Maschinensprache  übersetzt  werden.  Bei  der  Bedienung  die- 
ser Werkzeuge  gibt  es  viele  Möglichkeiten,  die  Geschwindigkeit  des  zu  erzeugen- 
den Programms  zu  beeinflussen.  Vorweg  sei  auf  die  Artikel  von  [Novillo05-1]  und 
[Novillo05-2]  hingewiesen,  die  einen  guten  Überblick  zu  Optimierungsoptionen  und 
zur  Geschwindigkeitsanalyse  bieten. 


5.4.1    Die  GNU  Compiler  Collection  [GCC] 

Die  GNU  Compiler  Collection51  ist  eine  Sammlung  von  Compilern  für  die  Program- 
miersprachen C,  C++,  Java,  Objective-C,  Fortran,  Ada  und  Go,  wobei  in  dieser  Arbeit 
lediglich  auf  die  Compiler  der  Sprachen  C  (gcc)  und  C++  (g++)  Bezug  genommen 
wird.  Diese  Sammlung  unterstützt  derzeit  (Juni  201 1)  bis  zu  60  verschiedene  Hardwa- 
replattformen52. 


5.4.2    Die  Wahl  der  optimalen  Compileroption 

Es  ist  keine  leichte  Aufgabe,  die  richtigen  Einstellungen  für  einen  Compiler  zu  finden, 
sodass  dieser  das  Programm  bestmöglich  optimiert.  Hierzu  wird  von  den  Compilerher- 
stellern53 und  in  der  Literatur54  für  die  jeweilige  Version  umfangreiches  Informations- 
material zur  Verfügung  gestellt.  Entscheidend  hierfür  ist  die  richtige  Wahl  der  jeweils 
benötigten  Einstellungen.  Bei  geeigneter  Optimierungseinstellung  kann  in  bestimmten 
Fällen  zwischen  20-40%  Laufzeit  eingespart55  werden.  Somit  ist  es  durchaus  lohnens- 
wert,  diesen  Bereich  genauer  zu  untersuchen. 


Mehr  Informationen  zu  dieser  Compilersuite  können  auf  der  Webseite  des  Projekts  nachgeschlagen 
werden:  http://www.pgroup.com/products/pgiworkstation.htm,  Download  15.11.2011 

49Nähere  Informationen  können  auf  der  Webseite  des  Compilerherstellers  nachgelesen  werden: 
http://www.caps-entreprise.com/index.php,  Download  15.11.2011 

50siehe  mehr  dazu  unter  http://user.cscs.ch/nc/news/index.html,  Download  15.1 1.201 1 

51  siehe  mehr  dazu  unter  [GNUCompiler],  [Gough04]  und  [VonHagen08] 

52siehe  mehr  dazu  unter  http://gcc.gnu.org/install/specific.html,  Download  22.06.201 1 

53  siehe  mehr  dazu  unter  [GNUCompiler] 

54siehe  mehr  dazu  unter  [VonHagen08],  ab  Seite  1 10 

55Information  aus  [Bulka99],  Seite  144 
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Abbildung  5.11:  Anzahl  der  aktivierten  Optimierungsoptionen  bei  vordefinierten  Op- 
timierungsstufen des  GNU-C  Compilers 


Wie  aus  Abb.  5.11  ersichtlich  wird,  wurde  im  Laufe  der  Zeit  eine  zunehmende  An- 
zahl verschiedener  Optimierungsoptionen  eingeführt,  mit  denen  das  zu  übersetzende 
Programm  auf  verschiedene  Art  und  Weise  optimiert  werden  kann.  Hatte  die  Version 
3.3  des  GNU-C  Compilers  noch  74  Optionen,  mit  denen  die  Optimierung  seitens  des 
Compilers  beeinflusst  werden  konnte,  so  besitzt  die  aktuelle56  Version  des  Compilers 
bereits  192  verschiedene  Optionen57.  Einige  dieser  Optionen  führen  zu  schnellen  Pro- 
grammen, wenngleich  aber  die  Größe  des  Programms  u.U.  zunehmen  kann.  Es  gibt 
auch  andere  Optionen,  welche  die  Größe  des  Programms  verringern,  dadurch  jedoch 
nicht  zwingend  die  Ausführungsgeschwindigkeit  erhöhen.  Um  dem  Benutzer  u.a.  die 
Nutzung  des  Werkzeugs  zu  vereinfachen,  wurden  von  den  Entwicklern  verschiedene 
Optimierungsstufen  eingeführt  (Ol,  02,  03,  Os).  Wird  eine  dieser  Optimierungsstu- 
fen ausgewählt,  so  wird  eine  bestimmte  vordefinierte  Untermenge  an  Optimierungs- 
optionen aktiviert.  Welche  Optimierungsoptionen  der  jeweiligen  Optimierungsstufe 
zugeordnet  sind,  hängt  von  der  Version  des  Compilers  ab.  Einer  bestimmten  Opti- 
mierungsstufe ist  jeweils  ein  Zweck  zugeordnet58 : 

•  Ol 

Hierbei  wird  versucht,  die  Übersetzungszeit  so  kurz  wie  möglich  zu  halten  und 
dennoch  das  Programm  zu  optimieren. 

•  02 

Bei  dieser  Stufe  erhöht  sich  die  Übersetzungszeit  und  es  wird  versucht,  das  Pro- 
gramm besser  zu  optimieren,  sodass  kürzere  Ausführungszeiten  erreicht  werden 
können. 

56gcc-4.6,  Juni  2011 

57Die  genaue  Anzahl  der  jeweils  aktivierten  Optionen  ist  in  Tabelle  El  auf  Seite  217  eingetragen. 
58  siehe  mehr  dazu  unter  [GNUCompiler] 
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•  03 

Dies  ist  die  stärkste  Optimierungsstufe.  Hierbei  werden  i.d.R.  die  meisten  Op- 
timierungsoptionen aktiviert,  was  zu  längeren  Übersetzungszeiten  als  bei  den 
niederen  Stufen  führt.  Ziel  dieser  Stufe  ist  es,  das  Programm  noch  stärker  zu 
optimieren,  um  noch  höhere  Ausführungsgeschwindigkeiten  zu  erreichen. 

•  Os 

Dabei  handelt  es  sich  um  eine  Ansammlung  von  Optimierungsoptionen,  welche 
das  Programm  auf  minimale  Größe  optimieren  soll.  Diese,  auf  minimale  Größe 
optimierten  Programme,  finden  oft  auf  Plattformen  im  embedded -Bereich  ihre 
Anwendung. 

Außerdem  wird  [Aho95-2]  (ab  Seite  715)  empfohlen,  dort  sind  Informationen  zur  Co- 
deoptimierung enthalten.  Außerdem  wird  beispielhaft  an  praktischen  Aufgabenstel- 
lungen gezeigt,  wie  eine  Leistungsverbesserung  für  bestimmte  Codefragmente  erzielt 
werden  kann.  Ferner  wird  ein  Einblick  in  Optimierungstechniken,  wie  sie  in  heutigen 
Compilern  vorzufinden  sind,  geboten. 

Soll  nun  eine  Kombination  aus  Compileroptionen  gefunden  werden,  die  das  Programm 
besser  optimieren  als  die  standardmäßig  vorgegebenen,  so  kann  das  Problem  kaum 
durch  Ausprobieren  bewältigt  werden.  Folgendes  Beispiel  verdeutlicht  dies: 

Beispiel  5.7  „Abschätzung  des  Aufwands  zum  Finden  der  besten  Kombination  von  Compi- 
lerflags  für  ein  Programm" 

Falls  beispielsweise  50  verschiedene  Compilerflags  vorhanden  sind  und  diese  sich  unter  Um- 
ständen wechselseitig  beeinflussen,  dann  ergeben  sich  daraus  250  Kombinationsmöglichkeiten. 
Dabei  müsste  für  jede  Kombination  ein  Programm  übersetzt  und  dessen  Laufzeitverhalten  be- 
wertet werden.  Würde  dies  im  Durchschnitt  eine  Sekunde  pro  Kombination  beanspruchen,  so 
würde  die  gesamte  Suche  250  Sekunden  dauern.  Damit  würde  dieser  gesamte  Test  etwas  mehr 
als  35  Millionen  Jahre  dauern. 

Ein  interessanter  Ansatz  wird  durch  das  Programm  ACOVEA  geboten.  Dieses  be- 
nutzt einen  Genetischen  Algorithmus  [GA],  dessen  Grundidee  der  biologischen  Evo- 
lution ähnelt.  Dabei  wird  eine  Menge  (hier  Compileroptionen)  von  Kombinationsmög- 
lichkeiten (Satz  von  Compileroptionen)  zufällig  generiert.  Anschließend  werden  diese 
Kombinationen  nach  einem  bestimmten  Gütekriterium  (geringste  Laufzeit)  selektiert. 
Daraus  (Compileroptionen)  werden  dann  nach  dem  Zufallsprinzip  die  Eigenschaf- 
ten (Hinzufügen  oder  Wegnehmen  von  Compileroptionen)  verändert  und  mit  ande- 
ren kombiniert  bzw.  gemischt.  Auf  diese  Art  und  Weise  wird  eine  neue  Generation 
geschaffen,  die  analog  zur  vorangegangen  behandelt  werden  kann  (Auslese  und  Kom- 
bination). Wird  dieser  Vorgang  einige  Male  wiederholt,  so  konvergiert  die  Lösung  in 
einem  lokalen  Minimum  (geringe  Laufzeit).  Ein  entscheidender  Nachteil  dieses  Ver- 
fahrens ist,  dass  nicht  garantiert  werden  kann,  ob  das  gefundene  Minimum  das  globale 
oder  nur  ein  lokales  Minimum  darstellt.  Ferner  sei  das  Buch  von  [Sauerl  1]  (ab  Seite 
268)  und  [Ladd95]  empfohlen.  Im  Weiteren  soll  ACOVEA  verwendet  werden,  um  ein 
Beispielprogramm  zu  optimieren. 

Beispiel  5.8  für  „Programmoptimierung  mit  ACOVEA" 

Um  die  Leistungsfähigkeit  von  ACOVEA  beurteilen  zu  können,  wurde  hier  anhand  einer  Fall- 
studie versucht,  einen  für  die  verwendete  Testplattform  (TP1)  geeigneten  Satz  an  Compiler- 
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Optionen  zu  finden.  Hierfür  wurde  ein  Testprogramm  erstellt,  welches  den  ungedämpften  Duf- 
fing  Oszillator  mit  Hilfe  des  Potenzreihenintegrators  löst  und  dabei  den  Dezimal  Datentyp 
verwendet.  Es  wurde  die  Aufgabenstellung  derart  gewählt,  dass  sich  eine  Ausführungszeit  von 
maximal  5  Millisekunden  ergibt.  Dafür  benötigte  ein  ACOVEA-Testlauf  im  Mittel  vier  Minu- 
ten Rechenzeit.  Insgesamt  wurden  vier  verschiedene  Testläufe  durchgeführt,  worin  ACOVEA 
jeweils  einen  Satz  an  Compileroptionen  ermittelte,  der  zu  besserem  Laufzeitverhalten  führte 
(verglichen  mit  den  gcc-4.3  Standardoptionen  —Ox).  In  Abb.  5.12  auf  Seite  128  sind  die  Lauf- 
zeiten (in  [ms])  aus  dem  Protokoll59  der  jeweiligen  ACOVEA  Testläufe  einander  gegenüberge- 
stellt. Dabei  sind  für  jeden  Testlauf  die  gemessenen  Laufzeiten  für  die  Standardoptionen  und 
ACOVEA-Optionen  angegeben.  Dementsprechend  wird  ersichtlich,  dass  ACOVEA  in  allen  vier 
Fällen  eine  Kombination  von  Optionen  finden  konnte,  die  zu  kürzeren  Laufzeiten  führte. 
In  Tabelle  5.5  sind  die  Compileroptionen  für  die  vier  Testläufe  eingetragen.  Dabei  fällt  auf, 
dass  ACOVEA  bei  allen  vier  Testläufen  neun  identische  Optionen  gefunden  hat.  Außerdem 
wurden  Optionen  gefunden,  die  bei  drei  Testläufen  übereinstimmten.  Es  scheint  also  eine 
Kombination  aus  Optionen  zu  geben,  mit  welcher  das  Programm  noch  besser  optimiert  wer- 
den kann.  Dies  wird  hier  jedoch  nicht  weiter  verfolgt,  da  die  Leistungsfähigkeit  von  ACOVEA 
bereits  demonstriert  wurde. 
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Abbildung  5.12:  Resultate  der  Simulationen  mit  ACOVEA 


Option 

Tl 

T2 

T3 

T4 

Option 

Tl 

T2 

T3 

T4 

-fno-merge-constants 

/ 

/ 

-fno-defer-pop 

/ 

/ 

-fno-inline 

/ 

-fpeel-loops 

/ 

/ 

-fno-omit-frame-pointer 

/ 

-fno-tree-ch 

/ 

-fvariable-expansion-in-unroller 

/ 

-fbranch-target-load-optimize2 

/ 

-fbtr-bb-exclusive 

/ 

-freorder-functions 

/ 

/ 

-momit-leaf-frame-pointer 

/ 

-minline-all-stringops 

/ 

-mfpmath=sse,387 

/ 

-mfpmath=sse 

/ 

Das  Protokoll  des  Testlaufs  Nr.  1  ist  exemplarisch  in  Anhang  El  auf  Seite  215  dargestellt. 
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-fno-delayed-branch 

-fno-loop-optimize 

/ 

/ 

-fstrength-reduce 

/ 

-frerun-cse-after-loop 

-fforce-addr 

/ 

/ 

-fno-tree-dse 

/ 

/ 

-fno-tree-dominator-opts 

/ 

/ 

-fregmove 

/ 

/ 

-fgcse-las 

/ 

-fivopts 

-fno-tree-ter 

/ 

-fsched-interblock 

/ 

/ 

-fcaller-saves 

/ 

/ 

-fmodulo-sched 

-fno-tree-lrs 

-fno-tree-sra 

/ 

-fno-tree-copyrename 

/ 

/ 

-fno-tree-fre 

/ 

/ 

-fno-move-loop-invariants 

-fcrossjumping 

/ 

-foptimize-sibling-calls 

-fcse-follow-jumps 

/ 

-fgcse 

-frerun-loop-opt 

/ 

-fpeephole2 

-fschedule-insns 

/ 

/ 

-fschedule-insns2 

-fdelete-null-pointer-checks 

-freorder-blocks 

-funit-at-a-time 

-falign-jumps 

/ 

/ 

-falign-loops 

-falign-labels 

-ftree-pre 

/ 

/ 

-linline-functions 

-funswitch-loops 

-fgcse-after-reload 

-fpredictive-commoning 

-falign-functions 

-falign-jumps 

/ 

-falign-labels 

/ 

-fprefetch-loop-arrays 

-ftree-vect-loop-version 

-ffloat-store 

/ 

/ 

-fprefetch-loop-arrays 

/ 

-funswitch-loops 

/ 

-funroll-loops 

/ 

/ 

-fbranch-target-load-optimize 

-fno-function-cse 

/ 

-fgcse-sm 

-freschedule-modulo-scheduled-loops 

-ftree-loop-linear 

/ 

/ 

-ftree-loop-im 

/ 

-ftree-loop-ivcanon 

/ 

/ 

-ftree-vectorize 

-mno-push-args 

-maccumulate-outgoing-args 

/ 

-mno-align-stringops 

/ 

/ 

-finline-limit=800 

/ 

-msse4.2 

/ 

Tabelle  5.5:  Ermittelte  gcc-4.3  Optimierungsoption  von  ACOVEA 


Weitere  Untersuchungen  zur  automatischen  Bestimmung  von  Compileroptionen 
wurden  von  [GranstonOl]  unternommen.  Hierbei  wurde  Hewlett-Packard's  PA-RISC 
Compiler60  verwendet,  um  für  dessen  Optimierungsoptionen  ein  Optimum  anhand  der 
jeweils  untersuchten  Aufgabenstellung  zu  finden.  Dabei  wurde  ein  Werkzeug  zur  Op- 
timierung entworfen,  welches  seine  Informationen  aus  drei  verschiedenen  Quellen  be- 
zieht und  basierend  auf  diesen  eine  Auswahl  geeigneter  Optimierungsoptionen  trifft. 
Es  werden  benutzerdefinierte  Optionen,  Informationen  aus  der  Übersetzung  des  Pro- 
gramms und  proüling  Information  genutzt,  um  daraus  eine  günstigere  Kombination 
an  Optimierungsoptionen  zu  erhalten.  Mit  dieser  kann  das  Programm  erneut  übersetzt 
werden  und  somit  besser  auf  die  jeweilige  Zielplattform  abgebildet  werden,  was  sich 
in  schnelleren  Programmlaufzeiten  widerspiegelt.  Hierbei  konnten  bestimmte  Unter- 
programme des  SPEC95-Benchmarks  footnotesiehe  mehr  dazu  unter  [SPEC95]  um 
das  Dreifache  schneller  ausgeführt  werden. 

Einen  ähnlichen  Ansatz  hierfür  verfolgt  [Haneda]61.  Dieser  verwendet  die  Version 
3.3.1  der  GNU  Compiler  Collection.  Hierbei  wurde  iterativ  vorgegangen  und  mit  ei- 
ner zufällig  generierten  Kombination  von  Compilerflags  begonnen.  Daraufhin  wurde 
ein  Testprogramm  übersetzt,  dessen  Ausführungszeit  gemessen  und  anschließend  be- 
urteilt. Dies  wurde  in  einem  Beispiel  für  5000  verschiedene  Kombinationen  durch- 
ziehe mehr  dazu  unter  http://h21007.www2.hp.com,  Download  am  22.06.201 1 
61  siehe  mehr  dazu  unter  [Haneda05-1]  und  [Haneda05-2] 
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geführt  und  es  konnte  gezeigt  werden,  dass  die  zufällig  erzeugten  Kombinationen  in 
vielen  Fällen  kürzere  Laufzeiten  erzielen. 

5.4.2.1  Fazit 

Das  Aufspüren  der  jeweils  besten  Kombination  an  Compileroptionen  ist  ein  sehr  auf- 
wendiges Unterfangen  und  verlangt  viel  Erfahrung  im  Umgang  mit  dem  verwendeten 
Compiler.  Da  sich  die  verschiedenen  Konfigurationsmöglichkeiten  bei  jeder  Version 
ändern,  erfordert  dies  zusätzliche  Einarbeitungszeit.  Außerdem  optimiert  der  Compi- 
ler das  jeweilige  Programm  auf  eine  bestimmte  Zielplattform,  die  unter  Umständen 
bestimmte  Eigenheiten  besitzt.  Auch  diese  sollten  die  Entwickler  kennen  um  ein  Op- 
timum zu  erreichen.  Falls  eine  Kombination  an  Einstellungen  gefunden  wird,  so  ist 
diese  optimal  auf  die  verwendete  Software  zugeschnitten,  d.h.  wird  an  der  Software 
etwas  verändert,  dann  muss  möglicherweise  erneut  gesucht  werden.  Viele  der  gezeig- 
ten Techniken  erleichtern  es,  die  Laufzeit  eines  bestimmten  Programms  zu  vermin- 
dern. Dennoch  muss  bei  jedem  Anwendungsfall  kritisch  hinterfragt  werden,  ob  der 
zeitliche  Aufwand,  bessere  Einstellung  zu  finden,  im  jeweiligen  Fall  gerechtfertigt  ist. 
Außerdem  gibt  es  eine  ganze  Reihe  von  Optimierungsoptionen,  die  durch  ungenaueres 
Rechnen  zwar  Laufzeit  einsparen62,  aber  das  Endergebnis  verfälschen.  Diese  sollten 
folglich  ignoriert  werden.  Ferner  ist  bei  der  Compileroption  -ansi63  Vorsicht  geboten. 
Diese  Option  sollte  während  der  Entwicklung  eines  Programms  aktiv  sein  um  ANSI/I- 
SO64 Kompatibilität  zu  gewährleisten.  Beim  fertiggestellten  Programm  sollte  sie  aber 
nicht  aktiviert  werden,  da  sonst  die  Laufzeit  erheblich  verlängert  werden  kann. 
Außerdem  soll  hier  noch  auf  das  Milepost  GCC65 -Projekt  hingewiesen  werden.  Hier- 
bei wurde  ein  lernender  Open-Source-Compiler  entwickelt,  welcher  in  der  Lage  ist, 
selbstständig  zu  erkennen,  wie  Quellcode  in  Maschinensprache  umgesetzt  werden  muss, 
um  die  Zielplattform  optimal  zu  nutzen.  Dabei  erlernt  dieser  auf  dem  GCC  basierende 
Compiler,  wie  sich  auf  einer  Hardwareplattform  die  höchste  Leistung  erzielen  lässt. 
Dazu  wurde  der  Compiler  um  Schnittstellen  ergänzt,  über  die  dieser  mit  Hilfe  von 
künstlicher  Intelligenz  Optimierungsvorschläge  ermitteln  kann.  Es  ist  wünschenswert, 
dass  dieses  ambitionierte  Projekt  in  den  Hauptentwicklungszweig  des  GCC-Projekts 
aufgenommen  wird.  Somit  wäre  es  für  eine  breite  Nutzergemeinde  einsetzbar,  was  oh- 
ne den  Aufwand  zusätzlicher  Softwarepakete,  wie  ACOVEA,  längerfristig  zu  schnel- 
leren Programmen  führen  würde. 

5.4.3    Weitere  geeignete  Compiler 

In  diesem  Abschnitt  sollen  die  verfügbaren  Compiler  für  das  Linux  Betriebssystem  be- 
züglich ihrer  Eigenschaften  verglichen  werden.  Hierfür  wird  zwischen  den  Sprachen 
C  und  C++  und  der  jeweiligen  Eignung  des  Compilers  hinsichtlich  der  Prozessorar- 
chitektur (32  oder  64  Bit)  unterschieden.  Diese  sind  in  Tabelle  5.6  aufgelistet.  Aus 
Gründen  der  Vollständigkeit  wurde  die  GNU  Compiler  Collection  ebenfalls  mit  in  die 
Liste  aufgenommen.  Es  wird  ersichtlich,  dass  die  meisten  der  ausgewählten  Compiler 

^Beispielsweise  -ffast-math 

63  siehe  mehr  dazu  unter  [Gough04]  auf  Seite  31 

64 Eine  Übersicht  zu  diesen  Standards  findet  man  auf  http://www.ansi.org/standards_activities 
65 siehe  mehr  dazu  unter  [cTuning],[FursinlO]  und  [Fursinl  1] 


5.4  Optimierung  während  der  Übersetzungsphase 


131 


auch  auf  64  Bit  Hardwareplattformen  und  Betriebssystemen  einsetzbar  sind.  Ferner  ist 
noch  zu  erwähnen,  dass  die  meisten  Compiler  sowohl  die  Programmiersprache  C  als 
auch  C++  unterstützen.  Aus  diesem  Grund  sind  fast  alle,  mit  Ausnahme  von  TCC  und 
PCC,  für  diese  Arbeit  geeignet.  Dabei  sei  angemerkt,  dass  die  32  und  64  Bit  Kom- 
patibilität des  Compilers  im  Rahmen  dieser  Arbeit  eine  untergeordnete  Rolle  spielt. 
Zur  Entwicklung  wurde  fast  ausschließlich  die  GCC  verwendet.  Darum  wäre  es  er-  [gcc]  g  nu 
strebenswert  herauszufinden,  welcher  der  hier  aufgelisteten  Compiler  das  schnellste  Compiler  Coiiection 
Programm  erzeugt,  d.h.  es  am  besten  optimiert.  Diese  Untersuchung  wird  hier  nicht 
durchgeführt,  da  dies  den  Rahmen  dieser  Arbeit  sprengen  würde.  Eine  Untersuchung, 
bei  der  drei  verschiedene  Compiler66  bezüglich  ihres  Optimierungsverhaltens  vergli- 
chen wurden  haben  gezeigt,  dass  beim  GCC-Compiler  viele  Optimierungsoptionen 
keinen  Vorteil  brachten  und  es  erhebliche  Unterschiede  zwischen  den  Compilersuiten 
gab. 


Name 

C 

C++ 

32  Bit 

64  Bit 

geeignet 

GCC 

/ 

/ 

/ 

/ 

CLang  Compiler67 

/ 

/ 

/ 

/ 

Solaris  Studio  Express  68 

/ 

/ 

/ 

/ 

x860pen64Compiler  6y 

/ 

/ 

/ 

/ 

Open64  Compiler70 

/ 

/ 

/ 

TCC71 

/ 

/ 

/ 

PCC72 

/ 

/ 

/ 

IntelOCompiler  B 

/ 

/ 

/ 

/ 

/ 

Rose  Compiler74 

/ 

/ 

/ 

/ 

PathScale  EKO  Compiler75 

/ 

/ 

/ 

Open  Watcom  Compiler  76 

/ 

/ 

/ 

Tabelle  5.6:  Gegenüberstellung  verschiedener  Compiler  für  Linux  mit  deren  Eigen- 
schaften 


In  Tabelle  5.6  sind  ausschließlich  Open  Source-Projekte  aufgeführt,  an  denen  ak- 
tiv entwickelt  wird77.  Es  gibt  eine  Vielzahl  weiterer,  prinzipiell  erwähnenswerter  Open 
Source-Compiler  Projekte,  deren  Weiterentwicklung  meist  aus  Zeitmangel  der  Betei- 
ligten eingestellt  wurde.  Da  in  dieser  Arbeit  das  Augenmerk  auf  optimierten  Program- 
men liegt,  sind  Compiler  dieser  Art  i.d.R.  nicht  relevant  und  werden  hier  bewusst  nicht 
weiter  erwähnt. 

66Siehe    mehr    dazu    unter  http://www.heise.de/developer/meldung/Compilervergleich-Intel-vor- 
Microsoft-vor-GCC-1469149.html,  Download  am  10.04.2012 
67  siehe  mehr  dazu  unter  [CLangCompiler] 
68siehe  mehr  dazu  unter  [SolarisStudioExpress] 
69siehe  mehr  dazu  unter  [x860pen64Compiler] 

70  siehe  mehr  dazu  unter  [Open64] 

71  siehe  mehr  dazu  unter  [TCC] 

72  siehe  mehr  dazu  unter  [PCC] 

73  siehe  mehr  dazu  unter  [IntelCompiler] 

74  siehe  mehr  dazu  unter  [RoseCompiler] 

75  siehe  mehr  dazu  unter  [PathScaleEKOCompiler] 

76  siehe  mehr  dazu  unter  [OpenWatcom] 
"Stand  Juli  2011 
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Kapitel  6 


Methoden  und  Aspekte  numerischer 
Differentiation 


Schwerpunkt  des  Kapitels: 

In  diesem  Abschnitt  werden  Aspekte  der  numerischen  Differentiation  betrachtet  und 
insbesondere  Formeln  zur  Berechnung  höherer  Ableitungen  entwickelt.  Diese  werden 
beispielsweise  benötigt,  falls  keine  analytische  Darstellung  einer  Funktion  vorliegt 
oder  die  höheren  Ableitungen  einer  gesuchten  Funktion  zu  aufwendig  zu  berechnen 
sind.  Darüber  hinaus  können  die  nachfolgend  erarbeiteten  Formeln  zur  Verifikation 
analytisch  berechneter  höherer  Ableitungen  herangezogen  werden.  Ferner  wird  die 
Technik  des  symbolischen  Differenzierens  und  die  Methode  des  automatischen  Diffe- 
renzierens anhand  des  Keplerproblems  beispielhaft  untersucht  und  bewertet. 
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6.1    Bestimmung  von  höheren  Ableitungen  mit  Hilfe  des  Dif- 
ferenzenquotienten 

Soll  eine  Funktion  f(x)  numerisch  differenziert  werden,  so  kann  der  so  genannte  Dif- 
ferenzenquotient zur  Berechnung  der  ersten  Ableitung  einer  stetig  differenzierbaren 
Funktion  verwendet  werden.  Dabei  ist  jedoch  Vorsicht  geboten,  da  hierbei  lediglich 
eine  angenäherte  Lösung  berechnet  wird.  Die  verschiedenen  Varianten  von  Differen- 
zenquotienten können  formell  wie  folgt  definiert  werden: 


Der  rechtsseitige  Differenzenquotient: 


f'(xo) 


lim 

x->0 


f(x0  +  h)  -  /(s0) 
h 


(6.1.1) 


Der  linksseitige  Differenzenquotient: 


f'(xQ) 


lim 


f(xo)  ~  f(xo  ~  h) 
h 


(6.1.2) 


Der  zentrale  Differenzenquotient: 


f'(x0)  w  lim 

x— >0 


f(xQ  +  h)  -  f(xQ  -  h) 
2h 


(6.1.3) 


In  Abb.  6.1  sind  die  unterschiedlichen  Varianten  der  Differenzenquotienten  geome- 
trisch interpretiert.  Dabei  ist  h  der  Abstand  der  zur  Berechnung  verwendeten  Funktions- 
werte. Daraus  wird  deutlich,  dass  zwischen  zwei  Punkten  ein  linearer  Zusammenhang 
unterstellt  wird,  der  unter  Umständen  nicht  mit  dem  tatsächlichen  Funktionswert  zu- 
sammenstimmt. 


X„+/l  x 


Abbildung  6. 1 :  Linksseitiger,  zentraler  und  rechtsseitiger  Differenzenquotient 


6.2    Lösungsformeln  zur  numerischen  Berechnung  höherer 
Ableitungsterme 

In  diesem  Abschnitt  sollen  auf  numerischem  Weg  höhere  Ableitungen  berechnet  wer- 
den. Diese  werden  insbesondere  benötigt,  falls  für  eine  gesuchte  Funktion  keine  ana- 
lytische Lösung  vorhanden  ist  oder  diese  zu  aufwendig  zu  berechnen  ist.  Dadurch 


6.2  LÖSUNGSFORMELN  ZUR  NUMERISCHEN  BERECHNUNG  HÖHERER  AßLEITUNGSTERME  135 


scheitert  der  intuitive  Ansatz  durch  Berechnung  des  Differenzenquotienten  häufig,  be- 
sonders wenn  die  verwendeten  Stützstellen  zu  nahe  beisammen  liegen  und  dadurch 
Auslöschungseffekte1  auftreten. 

Begriffsbestimmung  BEG6.1  „Numerische  Auslöschung": 

Dies  ist  ein  Effekt,  der  bei  Subtraktion  ähnlicher  Gleitkommazahlen  auftreten  kann.  Bei  kom- 
plexen Berechnungen  kann  nicht  vorhergesagt  werden,  ob  dieser  Effekt  auftritt  und  mit  wel- 
chem Genauigkeitsverlust  zu  rechnen  ist.  Konkret  tritt  dieser  Effekt  auf,  falls  zwei  Gleitkom- 
mazahlen fast  identische  Mantissenbits  besitzen  und  diese  subtrahiert  werden.  Dadurch  werden 
die  identischen  Bits  ausgelöst,  was  i.d.R.  ungenaue  Ergebnisse  verursacht.  Falls  sich  beispiels- 
weise nur  die  letzten  Bits  unterscheiden,  so  enthält  nach  der  Subtraktion  der  beiden  Zahlen 
die  Mantisse  des  Ergebnisses  im  ungünstigsten  Fall  nur  noch  ein  gültiges  Bit.  Ob  dieser  Effekt 
auftritt,  hängt  folglich  von  den  jeweils  subtrahierten  Zahlen  und  der  Anzahl  der  Mantissenbits 
ab. 

Beispiel  6.1  „Entwicklung  einer  Lösungsformel  zur  numerischen  Berechnung  der  ersten 
und  zweiten  Ableitung" 

Hier  wird  exemplarisch  eine  Lösungsformel  zur  Berechnung  der  ersten  und  zweiten  Ablei- 
tung einer  gegebenen  Funktion  f(x)  erarbeitet.  Im  ersten  Schritt  wird  von  einer  Taylorreihe 
4. Grades  ausgegangen: 

f(x)  =  /(.T0)  +  f'(x0)  +  \f"{x0)h2  +  \f^\x0)h?  +  l/(4)  (x0)/,4  +  0(h5)  (6.2.4) 

Es  werden  zusätzlich  zwei  Funktionswerte  benötigt.  Es  werden  die  Werte  f(x0  +  h)  und  f(x0  — 
h)  gewählt,  mit  einem  Abstand  von  2h.  Werden  die  beiden  Funktionswerte  eingesetzt,  dann 
können  die  beiden  Taylorreihen  wie  folgt  aufgestellt  werden: 

f(x0  -h)  =  f(xQ)     f'(x0)  +  \f"{x0)h2     lf^(x0)h3  +  ±fW(x0)h* 

(6.2.5) 

f(X0  +h)=  /(.T0)  +  /  (To)  +  -f"(x0)h2  +  -f(3Hx0)h3  +  -f^(x0)h4 

Werden  die  beiden  Reihen  als  ein  Gleichungssystem  mit  den  Unbekannten  f  [xq)  und  f  (xq) 
angesehen,  so  kann  es  formal  nach  den  Unbekannten  aufgelöst  werden.  Die  höheren  Ableitun- 
gen /(3)  und  /(4)  sind  in  diesem  Zusammenhang  als  Konstanten  zu  betrachten. 


/'M  =  f^  +  h)-f(x0-h)  +  i     (8)  + 

zh  o 

/'(«„)  =  f^  +  h)-2f(xa)  +  f(x-h)  _  _^2/(%o)  +  0{h4 


(6.2.6) 


Der  erste  Term  der  Gleichung  6.2.6  entspricht  der  Lösungsformel  zur  Berechnung  der  ersten 
Ableitung  (siehe  6.1).  Mit  dieser  Vorgehensweise  können  Lösungsformeln  für  die  Ableitungen 
/W, /(");  VneN  >  1,  gebildet  werden. 

Wie  gezeigt  wurde,  können  prinzipiell  für  beliebig  hohe  Ableitungen  Lösungs- 
formeln erarbeitet  werden.  Um  diese  Formeln  zu  berechnen,  werden  mehrere  Funk- 
tionswerte benötigt  und  es  muss  ein  entsprechend  höherer  Entwicklungsgrad  bei  der 
Taylorreihenentwicklung  gewählt  werden.  Im  nächsten  Unterpunkt  werden  in  analoger 
Vorgehens  weise  Lösungsformeln  erarbeitet,  mit  denen  Ableitungen  bis  zur  18.Ablei- 


'Ein  Beispiel  zur  damit  verbundenen  Fehlerrechnung  ist  in  [Press07]  auf  Seite  229  (unten)  zu  finden. 
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tung  berechnet  werden  können. 

Beispiel  6.2  für  „Erstellung  von  Lösungsformeln  zur  numerischen  Berechnung  höherer  Ab- 
leitungen" 

Das  Erarbeiten  von  Lösungsformeln  für  höhere  Ableitungen  ohne  technische  Hilfsmittel  ist 
zwar  prinzipiell  möglich,  würde  aber  zu  lange  dauern.  Aus  diesem  Grund  wird  auf  ein  Hilfs- 
programm zurückgegriffen,  das  von  [Mathews03 ]  entwickelt  wurde.  Dieses  Programm  wurde 
mit  MATHEMATICA2  entwickelt  und  verwendet  den  zentralen  Differenzenquotienten  zur  Er- 
mittlung der  höheren  Ableitung.  Die  Vorgehensweise  zur  Bestimmung  der  Lösungsformeln  ist 
dabei  analog  zur  bereits  gezeigten  (siehe  Abschnitt  6.2). 


CentralDif f [ k0_ ]  :  =  Module [ {k  =  kO} , 
Clear [h,  i,  j  ,  n,  f ,  s,  x]  ; 

s  [h_]  =  Normal  [Series  [f  [x0  +  h]  ,  {h,  0  ,  2  k  +  2}  ]  ]  ; 
eqns  =  Table  [s  [  j  h]  ==  f  [x0  +  j  h]  ,  { j  ,  -k,  k}  ]  ; 

vars  =  Table  [f(k)  [x0]  ,  {k,  1,  2  k}]; 

pts  =  Table  [{x0,  f  [x0  +  j  h]  }  ,  { j  ,  -k,  k}  ]  ; 

solset  =  Solve[eqns,  vars] ; 

solsetj! , ah, 2j  =  Collect  [ExpandAll  [solset  ji, aii, 2j  ]  ,  h]  ; 

solset|[i,Äii,2,2i  =  ReplaceAll  [solset m, ah, 2,2i ,  f  CO  Ixo]  -»f  U)  [c]  ]  ; 

solsetttl,Aii,2,ii  =  Together  [ solset ah, 2, ij]  ; 
Print [ 

"Central  difference  formulas  for  numerical  dif f erentiation" ] ; 
Print  ["Using  the  ",2k  +  l,  "  points"  ]; 
Print  [  pts,  "\n"  ]  ; 
Print  [TableForm  [solsetjij  ]  ]  ;  ]  ; 

Abbildung  6.2:  Mathematica  Funktion  zur  symbolischen  Berechnung  von  Formeln  zur 
Bestimmung  höherer  Ableitungen 

Die  Funktion,  welche  zur  Berechnung  herangezogen  wurde,  ist  aus  Gründen  der  Vollständig- 
keit in  Abb.6.2  dargestellt.  Dieses  Programm  benötigt  zur  Berechnung  lediglich  die  Anzahl 
m~1  der  zu  verwendeten  Stützstellen.  Es  wird  jeweils  eine  ungerade  Anzahl  von  Stützstellen 
verwendet,  da  der  symmetrische  Differenzenquotient  und  der  Entwicklungspunkt  der  Taylor- 
reihe benötigt  wird.  Falls  beispielsweise  fünf  Stützstellen  (m  —  5)  verwendet  werden  sollen, 
ist  die  Funktion  mit  CentmlDiff[2]  aufzurufen  (k  =  2).  Somit  ergibt  sich  folgender  Zusammen- 
hang: 

m  =  2k  +  l  (6.2.7) 

Um  eine  Lösungsformel  für  die  18.  Ableitung  zu  erhalten,  muss  das  Programm  konsequenter- 
weise mit  CentralDiff[9]  aufgerufen  werden.  Damit  werden  folgende  19  Funktionswerte  zur 
Berechnung  der  höheren  Ableitungen  benötigt: 

f(-9h  +  x0),  f(-8h  +  x0)J(-7h  +  x0),f(-6h  +  so) 
f(-5h  +  x0),  f(-4h  +  x0)J(-3h  +  x0),f(-2h  +  x0) 
f(h  +  xQ)J(+xQ),  f(h  -  x0) 
f(2h  +  x0)J(3h  +  x0),  /(4h  +  x0),  f(5h  +  x0) 
f{Qh  +  x0)J(7h  +  x0),  f(8h  +  xo),  f(9h  +  .t0) 


2siehe  mehr  dazu  unter  http://www.wolfram.com/mathematica/ 
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Im  Folgenden  werden  die  Formeln  für  die  ersten  vier  Ableitungen,  basierend  auf  19  Funktions- 
werten dargestellt.  Alle  weiteren  Formeln  sind  im  Anhang  E  auf  Seite  209  zu  finden. 

f{x0)  =  1225^24Qfe(-28/(-9/i  +  x0)  +  567 / (-8h  +  x0)  -  5508/(-7/i  +  x0) 

+  34272/(-6/i  +  x0)  -  154224/(-5/i  +  x0)  +  539784/(-4/i  +  x0) 

-  1559376/ (-3/i  +  x0)  +  4009824/(-2/i  +  xa)  -  11027016/(-/i  +  x0) 
+  11027016/O  +  z0)  -  4009824.f(2/i  +  z0)  +  1559376/(3/i  +  x0) 

-  539784/(4/t  +  x0)  +  154224/(5/i  +  z0)  -  34272/(6/i  +  x0) 
+  5508/(7/i  +  x0)  -  567/(8/i  +  x0)  +  28/(9/i  +  x0)) 


f'W  =  15437822400^  (-47541321542/(-0)  +  7840'H*  + 

-  178605/(-8/i  +  x0)  +  1982880/(-7/i  +  x0)  -  14394240/(-6/i  +  x0) 

+  77728896/(-5/i  +  xQ)  -  340063920/(-4/t  +  x0)  +  1 309875840/ (-3h  +  x0) 

-  5052378240/(-2/i  +  x0)  +  27788080320/(-/i  +  x0)  +  27788080320/ (ft  +  x0) 

-  5052378240/(2/i  +  x0)  +  1309875840/(3/i  +  x0)  -  340063920/ (Ah  +  x0) 
+  77728896/(5/i  +  x0)  -  14394240/(6/i  +  x0)  +  1982880/(7/i  +  x0) 

-  178605/(8/i  +  x0)  +  7840/(9/i  +  x0)) 


fi3){xo)  =  3027024000^  (63397/(~9fe  +  Xo)  "  1281033/(-8fe  +  *o) 

+  12405267/(-7h  +  xa)  -  76813928/(-6/i  +  x0)  +  342868500/(-5/i  +  x0) 

-  1182036366/(-4/i  +  x0)  +  3302404924/ (-3h  +  x0)  -  7666346376/(-2/i  +  xQ) 
+  8823005334/(-h  +  x0)  -  8823005334/(/i  +  x0)  +  7666346376/ (2h  +  xQ) 

-  3302404924/(3/i  +  x0)  +  1182036366/ (Ah  +  x0)  -  342868500/(5/i  +  x0) 
+  76813928/(6/i  +  x0)  -  12405267/(7/i  +  xQ)  +  1281033/(8/i  +  xQ) 

-  63397/(9/i  +  x0)) 


~  54486432000/i4  (842762184550/(a;o)  -  507176/(-9ft  +  xQ) 

+  11529297/(-8fr  +  x0)  -  127597032/(-7/i  +  x0)  +  921767136/(-6/i  +  xQ) 

~  4937306400/(-5/i  +  x0)  +  21276654588/(-4/i  +  x0)  -  79257718176/(-3/i  +  x0) 

+  275988469536/(-2/i  +  x0)  -  635256384048/ (-h  +  xa)  -  635256384048/(/i  +  xa) 

+  275988469536/(2/i  +  x0)  -  79257718176/(3/i  +  x0)  +  21276654588/(4/i  +  x0) 

-  4937306400/(5/i  +  xQ)  +  921767136/(6/i  +  x0)  -  127597032/(7/i  +  x0) 

+  11529297/(8/i  +  x0)  -  507176/(9/i  +  x0)) 


Beispiel  6.3  für  „Verifikation  der  Lösungsformeln  anhand  des  Duffing-Oszillators" 

In  diesem  Beispiel  werden  die  erarbeiteten  Lösungsformeln  anhand  der  Ableitungen  des  unge- 
dämpften Duffing-Oszillators  validiert.  Hierzu  werden  die  dafür  benötigten  numerischen  Werte 
der  Ableitungsterme  mit  dem  Potenzreihenintegrator  mit  entsprechend  hoher  Genauigkeit  be- 
rechnet. Diese  können  zum  Vergleich  herangezogen  werden  und  in  diesem  Zusammenhang  als 
Referenzlösung  angesehen  werden.  Ferner  besteht  bei  den  Formeln  eine  zusätzliche  Abhän- 
gigkeit zum  Parameter  h.  Dieser  beeinflusst  die  Qualität  des  Ergebnisses,  wie  aus  Abb.  6.3 
ersichtlich  wird. 


138 


Kapitel  6:  Methoden  und  Aspekte  numerischer  Differentiation 


Abbildung  6.3:  Überprüfung  der  Lösungsformeln  mit  unterschiedlicher  Schrittweite 


Hier  wurden  alle  geraden  Ableitungsterme3  bis  zur  18.Ableitung  der  Referenzlösung  gegen- 
übergestellt. Um  die  Abhängigkeit  des  Parameters  h  sichtbar  zu  machen,  wurde  dieser  sukzes- 
sive verkleinert  (siehe  x-Achse).  Aus  dem  relativen  Fehler  (y-Achse)  der  jeweiligen  Berechnung 
wird  ersichtlich,  dass  es  für  jeden  Ableitungsterm  ein  optimales  h  gibt,  welches  die  besten  Er- 
gebnisse liefert.  Die  Herausforderung  besteht  nun  darin,  ein  optimales  h  zu  finden,  um  den 
relativen  Fehler  pro  Ableitungsterm  zu  minimieren.  Außerdem  ist  auffällig,  dass  die  erreich- 
bare Genauigkeit  mit  steigendem  Grad  der  Ableitung  abnimmt.  Um  dies  zu  überprüfen,  wurde 
ein  weiterer  Satz  an  Formeln  erstellt,  welcher  13  Punkte  zur  Berechnung  eines  Ableitungs- 
wertes benötigt.  Die  Ergebnisse  aus  dem  Vergleich  mit  der  Referenzlösung  sind  in  Abbildung 
6.4  dargestellt.  Darin  ist  ebenfalls  eine  Abnahme  der  relativen  Genauigkeit  bei  zunehmenden 
Ableitungsgrad  zu  erkennen. 


3Durch  die  gewählten  Startwerte  (u  =  1,  ü  =  0)  des  ungedämpften  Duffing-Oszillators  haben  alle 
ungeraden  Ableitungsterme  den  Wert  Null  und  werden  nicht  berücksichtigt. 
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10. Abi 

le-05   -      12. Abi 


Abbildung  6.4:  Überprüfung  der  Lösungsformel  mit  unterschiedlicher  Schrittweite 


Beispiel  6.4  für  Algorithmus  zur  Verbesserung  der  Lösung" 

Es  soll  ein  Algorithmus  angegeben  werden,  mit  dem  die  Ableitungswerte  noch  verbessert  wer- 
den können.  Wie  im  vorangegangenen  Beispiel  gezeigt  wurde,  hängt  die  Qualität  des  Ergebnis- 
ses einer  bestimmten  Ableitung  von  der  gewählten  Schrittweite  h  ab.  Dieses  Problem  wurde  in 
ähnlicher  Form  schon  von  [Ridders82  ]  gelöst,  jedoch  nur  für  die  Ableitungen  ersten  und  zwei- 
ten Grades.  Aus  dieser  Vorgehensweise  soll  nun  eine  Methode  für  höhere  Ableitungen  erstellt 
werden.  Hierzu  wird  analog  zum  Vorgehen  von  [Ridders82]  in  einer  Anlaufphase  ein  Satz  von 
Ableitungswerten  f^(i  €  N+  )  berechnet,  wobei  bei  jeder  der  Berechnungen  die  Schrittweite 
h  halbiert  wird.  Nach  dieser  Anlauf phase  liegt  folgender  Satz  an  Ableitungswerten  vor: 


/(i)(y),/(i)(^/W(^),/(i)(f), 


(6.2.8) 


wobei  N  ein  Platzhalter  für  die  Anzahl  der  Unterteilungen  während  der  Anlaufphase  ist.  Ab- 
kürzend kann  der  Satz  an  Ableitungswerten  als  A1: An  bezeichnet  werden1.  Im  nächsten 
Schritt  wird  auf  die  Methode  der  Richardson  Extrapolation  zurückgegriffen,  welche  auch  beim 
Integrationsverfahren  von  Burlisch  und  Stoer  verwendet  wird.  Dieses  Verfahren,  einschließlich 
der  Richardson  Extrapolation,  ist  in  Abschnitt  2.3.5.3  auf  Seite  25  beschrieben.  Als  nächstes 
können  zwei  aufeinander  folgende  Werte  verwendet  werden,  um  daraus  mit  Hilfe  der  Richard- 
son Extrapolationsmethode  eine  Verbesserung  B  zu  erzielen.  Das  kann  beispielsweise  für  die 
erste  Verbesserung  wie  folgt  durchgeführt  werden5 : 


_      A2hm  -  Ax 

B\  =  —  — ,  m  =  1 

hm  -  1 


(6.2.9) 


Werden  die  Verbesserungen  sukzessive  durchgeführt,  dann  ergibt  sich  das  in  Abbildung  6.5 


Hierbei  wird  die  Nomenklatur  von  [Ridders82]  übernommen. 

5Es  wird  hier  lediglich  die  Formel  der  Richardson-Extrapolation  auf  diese  Problemstellung  angewen- 
det. Siehe  mehr  dazu  in  [Ridders82]. 
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schematisch  dargestellte  Schema  .  Hierbei  ist  der  Buchstabe  C  ein  Platzhalter  für  einen  wei- 
teren Verbesserungszyklus. 

A-i        A3  A*  A^  Ar 

V 171/ 1/17 

Bl  B-,  B3  B4  B5  ... 

17 17 17 17 
17 17 17 

Abbildung  6.5:  Schema  zur  Verbesserung  der  Lösung  durch  Richardson  Extrapolation 

Um  ein  Abbruchkriterium  zu  erhalten,  sind  im  Fall  der  ersten  Verbesserungsiteration  (B)  fol- 
gende zwei  Fehlerbeträge  zu  bestimmen: 

e1  =  \B2  -  Bi\ 
e2  =  \B2-Ai\ 

Anschließend  wird  der  größere  der  beiden  Werte  mit  dem  e  der  letzten  Iteration  verglichen. 
Ist  dieses  e  kleiner,  so  wurde  die  Lösung  verbessert  und  kann  zwischengespeichert  werden.  Im 
anderen  Fall  wurde  keine  Verbesserung  erzielt,  die  Lösung  wird  verworfen  und  eine  neue  Itera- 
tion begonnen.  Als  Anfangsbedingung  wird  hierbei,  analog  zur  Implementierung  in  [Press07f , 
der  Wert  von  e  =  1.797693e  +  308  gesetzt.  In  Abb.  6.6  sind  die  Ergebnisse  der  Verbesserungen 
der  beiden  Formeln,  bestehend  aus  13  und  19  Stützstellen,  dargestellt.  Bei  den  jeweils  ver- 
besserten Lösungen  fällt  auf,  dass  die  Richardson  Extrapolationsmethode  gerade  bei  hohen 
Ableitungen  die  Ergebnisse  derart  gut  verbessert,  dass  der  relative  Fehler  stets  im  Bereich  von 
1.0E-40  bleibt.  Bei  den  nicht  verbesserten  Lösungen  wurde  dieselbe  Schrittweite  verwendet, 
welche  durch  das  Verbesserungsverfahren  ermittelt  wurde,  jedoch  verschlechterte  sich  das  Er- 
gebnis mit  zunehmenden  Grad  der  Ableitung.  Dieser  Trend  konnte  bereits  aus  Abb.  6.3  und  6.4 
abgeleitet  werden. 


6Diese  ist  in  ähnlicher  Weise  in  [Scheid88]  auf  Seite  1 14  (Abschnitt  13.30)  abgedruckt. 
7  Hier  wird  eine  ähnliche  Implementierung  angegeben.  Sie  mehr  dazu  auf  Seite  253.  Die  dort  definierte 
Funktion  lautet  dfridr. 
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le-15 


le-30 


le-35 


2  4  6  8  10  12  14  16  IG 

Ableitungsterm 

Abbildung  6.6:  Verbesserung  durch  Richardson  Extrapolation 

6.3    Weitere  Methoden  der  Differentiation 

In  diesem  Abschnitt  sollen  weitere  Methoden  der  Differentiation  betrachtet  werden. 
Neben  den  bereits  erarbeiteten  Lösungsformeln  kann  durch  symbolisches  Differenzie- 
ren -  eine  gegebene  Funktionsdefinition  vorausgesetzt  -  die  formelmäßige  Darstellung 
der  Ableitungsfunktion8  streng  mathematisch  berechnet  werden. 
Ist  die  Aufgabenstellung  bereits  als  Computerprogramm  realisiert,  so  bietet  sich  auto- 
matisches Differenzieren  (AD)  an.  Hierbei  werden  nicht  wie  beim  numerischen  Dif- 
ferenzieren die  entsprechenden  Differenzenquotienten  berechnet,  sondern  es  wird  aus 
dem  bestehenden  Computerprogramm  eine  erweiterte  Funktion  generiert.  Mit  Hilfe 
dieser  generierten  Erweiterung  ist  es  prinzipiell  möglich,  beliebig  hohe  Ableitungs- 
terme  zu  errechnen.  Diese  generierte  Funktion  besteht  ausschließlich  aus  mathemati- 
schen Grundfunktionen  (z.B.  sin,  cos, ...),  deren  Ableitungen  bekannt  sind  und  exakt 
berechnet  werden  können.  Durch  Anwenden  der  Kettenregel  auf  die  Ausgangsfunkti- 
on9 und  mit  dem  Wissen,  wie  die  Ableitungen  der  Grundfunktionen  beschaffen  sind, 
lassen  sich  somit  Funktionen  generieren,  die  das  Ergebnis  der  jeweils  gewünschten 
Ableitung  liefern. 

Der  Zusammenhang  zwischen  den  Techniken  der  symbolischen  und  automatischen 
Differentiation  ist  in  Abb.  6.7  dargestellt.  Wird  eine  symbolisch  vorhandene  Funktion 
differenziert,  so  wird  diese  in  vielen  Fällen  in  Quelltext  (Computerprogramm)  übertra- 
gen. Dieser  Vorgang  ist  bei  umfangreichen  Funktionen  besonders  zeitaufwendig  und 
führt  dabei  oft  zu  Übertragungsfehlern.  Das  Auffinden  dieser  kann  unter  Umständen 
viel  Zeit  in  Anspruch  nehmen.  Im  Gegensatz  dazu  bietet  das  automatische  Differenzie- 

8Dies  setzt  eine  stetig  differenzierbare  Funktion  der  untersuchten  Problemstellung  voraus. 
'Zusätzliche  Informationen  zum  automatischen  Differenzieren  gibt  es  auf  folgender  Webseite: 
http://www.autodiff.org/ 
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ren  die  Möglichkeit,  ohne  derartige  Übertragungsfehler  eine  funktionale  Implementie- 
rung der  Ableitungsfunktion  zu  generieren. 


Symbolische 
Darstellung 


y=f(*) 


Ubertrag  in 
Computerprogramm 


■ 


Darstellung  als 
Computerprogramm 


voidf(x){...} 


Manuelles  oder 
symbolisches 
Differenzieren 
mit  CAS 


Manuelles  oder 
automatisches 
Differenzieren 


y 


,  df(x) 


dx 


Übertrag  in 
Computerprogramm 


voiddf{xY 


'  L  *■■  J 


-  Aufgabenstellung 


>  Differential 

J 


Abbildung  6.7:  Zusammenhang  zwischen  symbolischer  Ableitung  und  Bestimmung 
einer  Ableitung  mittels  automatischer  Differentiation 


Beispiel  6.5  für  „Berechnung  höherer  Ableitungen  des  Keplerproblems  mit  Hilfe  symboli- 
scher Rechnung" 

In  diesem  Beispiel  soll  die  dritte  Ableitung  des  Keplerproblems  auf  symbolischem  Weg  berech- 
net werden.  Die  folgenden  Variablen  werden  als  gegeben  vorausgesetzt: 


y(t) 

r=  y(t) 
H  =  GMä 


r=y/x2(t)+y*(t)  +  z*(t)\ 

.      dr      2z  (t)  (ftz  (*))  +  2y  (t)  (£y  (t))  +  2x  (t)  (£x  (f)) 


dt 


2y/z*  (t)  +  y2  (i)  +  x2  (t) 


[rr\ 
r 


ist: 


r  der  Ortsvektor  im  Inertialsystem  und  r  die  geometrische  Distanz. 


r  der  Vektor  der  Geschwindigkeitskomponenten  und  r  die  Radialgeschwindigkeit. 


ji  die  Gravitationskonstante  G  multipliziert  mit  der  Masse  der  Erde  Mffi. 


•  t  die  Zeit. 
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Durch  Anwenden  der  bekannten  Regeln  der  Differentiation10  ergeben  sich  folgende  Ergebnis- 
sen: 

d°r 

d}f 
dt? 
d?r 
dt2 
d^r 
dt3 

Nachdem  die  Ableitungsterme  formelmäßig  bestimmt  sind,  können  sie  in  ein  Computerpro- 
gramm übertragen  werden.  Eine  mögliche  Implementierung  der  Kraftfunktion  und  der  3.  Ab- 
leitung ist  in  Listing  6.1  und  6.2  angegeben. 


1 

#include  <math.h> 

2 

#define  GME  0.3986004415000000E+6  /*  /femA 

3/s]  */ 

3 

void   Kepler ( double  *x ,    double   *y ,  double 

*z  , 

4 

double   *vx,    double   *vy ,    double  *vz) 

5 

{ 

6 

double  r ,   _x ,  _y ,   _z ; 

7 

_x  =  *x;   _y  =  *y ;   _z  =  *z; 

8 

r  =     sqrt(   (_x)   *   (_x)  +  (_y)   *   (_y)  + 

(_z)   *   (_z)  ); 

9 

r  *=  r  *  r  ; 

10 

*x     =  *vx; 

11 

*y     =  * vy ; 

12 

*z     =  * vz ; 

13 

*vx  =  —  GME  *  _x  /r; 

14 

*vy  =  —  GME  *  _y  /r; 

15 

*  vz  =  —  GME  *     z   /  r  ; 

16 

} 

Listing  6.1;  Implementierung  der  Keplerkraftfunktion  (^f)  in  der  Programmiersprache  C  aus  symbolischer 
Rechnung 


1 

void   dKepler  (  double  *x, 

double  *y,    double   *z ,    double  vx ,    double  vy , 

double  vz ) 

2 

{ 

3 

double  r ,   r3 ,   r5    ,   rv ; 

4 

r  =     sqrt(   (*x)   *  (*x) 

+  (*y)   *   (*y)  +  (*z)   *   (*z)  ); 

5 

rv  =  (   (*x  *  vx)  +  (*y 

*  vy)  +  (*z  *  vz)  ); 

6 

r3  =  r  *  r  *  r  ; 

7 

r5  =  r3  *r*r  ; 

8 

*x  =  -  GME  *  (  (vx)/r3 

—  3*(*x)   *  rv/r5    )  ; 

9 

*y  =  —  GME  *   (  (vy)/r3 

—  3*(*y)   *  rv/r5    )  ; 

10 

*z  =  -  GME  *  (  (vz)/r3 

—  3*(*z)   *  rv/r5    )  ; 

11 

} 

Listing  6.2:  Implementierung  der  3.  Ableitung  (^jr)  in  der  Programmiersprache  C  aus  symbolischer  Rechnung 


Produkt  -u.  Kettenregel  der  Differentialrechnung:  Siehe  mehr  dazu  in  [Bronstein08]  auf  Seite  435 
und  436. 

"im  Anhang  C  (Seite  191)  sind  Formeln  bis  zur  1  O.Ableitung  angegeben. 


=  r 

r 


144 


Kapitel  6:  Methoden  und  Aspekte  numerischer  Differentiation 


Eine  alternative  Möglichkeit,  eine  Implementierung  der  3.  Ableitung  zu  erhalten,  stellt 
automatisches  Differenzieren  dar. 

Beispiel  6.6  für  „Bestimmung  der  3.Ableitung  durch  automatisches  Differenzieren" 

[AD]  Automatisches  Als  Ausgangspunkt  zum  AD  wird  die  abzuleitende  Funktion  in  einer  i.d.R.  frei  wählbaren  Pro- 
Differenzieren  grammiersprache  als  Funktion  implementiert.  Diese  wird,  im  Sinne  der  Differentiation,  ge- 

wöhnlich als  Basisfunktion  bezeichnet.  Zur  Bestimmung  der  Ableitungsfunktion  aus  der  Basis- 
funktion stehen  prinzipiell  zwei  unterschiedliche  Algorithmen  zur  Verfügung,  der  Vorwärts  - 
u.  Rückwärtsmodus12.  Beide  Algorithmen  basieren  dabei  auf  der  Grundidee,  aus  einer  Basis- 
funktion, welche  aus  mathematischen  Grundoperationen  aufgebaut  ist,  eine  Ableitungsfunktion 
zu  generieren.  Wird  der  Vorgang  der  Ableitung  als  Aufrufgraph  angesehen,  so  unterscheiden 
sich  die  beiden  Ansätze  lediglich  in  der  Abarbeitungsreihenfolge.  Darüber  hinaus  gibt  es  zwei 
unterschiedliche  Vorgehensweisen,  eine  automatische  Differentiation  durchzuführen: 

1.  Source  Code  Transformation  [SCT] 

Hierbei  wird  die  Basisfunktion  lediglich  eingelesen  und  daraus  eine  Ableitungsfunktion 
generiert.  Diese  minimal  invasive  Technik  kann  prinzipiell  auf  eine  beliebige  Program- 
miersprache angewendet  werden. 

2.  Operatorüberladung 

Diese  Methode  erfordert  u.  U.  die  Veränderung  des  Quelltextes,  falls  dieser  nicht  ob- 
jektorientiert programmiert  wurde.  Außerdem  ist  eine  Änderung  einiger  Datentypen 
auf  den  Dualzahlen-Datentyp  erforderlich.  Da  dieser  kein  Standarddatentyp  der  C- 
Standardbibliothek  ist,  enthalten  die  meisten  AD-Bibliotheken  eigene  Implementierun- 
gen für  Dualzahlen.  Die  Vorgehensweise  zum  Differenzieren  ist  in  Abb.  6.8  schematisch 
dargestellt. 


Siehe  mehr  dazu  in  [Bücker06] 
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Source  Code  Transformation 


Basisfunktion 


int  f(){ ... }  \^Compiler 
AD-Tool 


Computerprogramm 


Ableitungsfunktion -i    intdf(){--}  </ComP'ler 


Objektorientiert 


Basisfunktion 

(objektorientiert) 


AD-Tool  Bibliothek 


intfO{ 

1 

Modifikation  des 
Quellcodes  der 
Basisfunktion 

Compiler 


class  DualType  //Compiler 


Computerprogramm 


Abbildung  6.8:  Schematische  Darstellung  der  Vorgehensweise  beim  automatischen 
Differenzieren  mit  objektorientiertem  und  SCT-Ansatz 


Die  Aufgabenstellung  des  vorausgegangenen  Beispiels  wird  nun  wieder  aufgegriffen  und  mit- 
tels SCT-Vorwärtsmodus  wird  eine  Ableitungsfunktion  bestimmt.  Hierfür  wurde  der  Online- 
Dienst  TAPENADE13  verwendet.  Das  Resultat  der  Quelltexttransformation  ist  in  Listing  6.3 
dargestellt14.  Vergleicht  man  den  Quelltext  der  automatischen  Differentiation  mit  dem  der  sym- 
bolisch bestimmten  Lösung,  so  wird  ersichtlich,  dass  die  generierte  Lösung  mehr  Rechenopera- 
tionen benötigt.  Verglichen  mit  manueller  Implementierung  und  dem  damit  verbundenen  Zeit- 
aufwand, ist  diese  Methode  erheblich  effizienter.  Im  Anhang  G.ll  (Seite  231)  ist  der  Quelltext 
für  den  Rückwärtsmodus  angegeben.  Beim  Vergleich  der  resultierenden  Ableitungsfunktionen, 
welche  im  Vor-  bzw.  Rückwärtsmodus  gebildet  wurden,  fällt  auf,  dass  die  Anzahl  der  benötigten 
arithmetischen  Operationen  für  die  Berechnung  des  Vorwärtsmodus  geringer  ist. 

void  dKepler ( double   *x ,    double   *xd ,    double  *y ,    double   *yd,    double   *z , 
double   *zd ,    double   *vx ,    double   *vxd ,    double  *vy ,    double   *vyd , 


double 

*vz ,    double  * vzd ) 

2  { 

3 

double 

r ,  _x  ,   _y  ,   _z ; 

4 

double 

rd  ,   _xd  ,   _yd  ,   _zd  ; 

5 

double 

argl  ,    argld    ,  GME; 

6 

GME  = 

0. 39860044 15000000E+6; 

7 

xd 

=  *xd;     _x  =  *x; 

8 

_yd 

=  *  yd  ;      _y  =  *  y  ; 

9 

_zd 

=  *  zd  ;     _z  =  *  z  ; 

13Siehe  mehr  dazu  unter  http://www-tapenade.inria.fr:8080/tapenade/paste.jsp,  Download  am 
10.04.2012 

14Der  abgedruckte  Quelltext  wurde  formatiert,  um  Platz  zu  sparen. 
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10 

y  H  *    y    4-      y*    yH    -t-      vH  *    v    -t-      v  *    vH    -4-      7  H  *    7  4- 

11 

ar  2 1 

x  *  x  +    y  *  y  +          z  ; 

12 

rd 

farffl    ==   0  0    ?   0  0    ■    ar?ld/f2  0*  sart(arp|  ))1 

13 

r 

ö4iLVai5i ) ' 

14 

rd 

( rH^r-t-r^rH^^r    -(-    r  ^       rH  * 

1  J 

r 

r  *  r  ^ 

16 

*xd 

*  vxd  ;       *x  =  *  vx  ; 

17 

*yd 

*vyd;       *y  =  *vy; 

18 

*zd 

*vzd ;       *z  =  * vz ; 

19 

*vxd 

(GME*_x*rd-GME*_xd*r  )  /(  r*r)  ; 

20 

*  vx 

-GME*_x/  r  ; 

21 

*  vyd 

(GME*_y*rd-GME*_yd*r  )  /(  r*r)  ; 

22 

*  vy 

-GME*_y/r  ; 

23 

*  vzd 

(GME*_z*rd-GME*_zd*r  )  /(  r*r)  ; 

24 

*  vz 

-GME*_z/  r  ; 

25  } 

Listing  6.3:  Implementierung  der  3.  Ableitung  (^pr)  in  der  Programmiersprache  C  durch  automatisches 
Differenzieren  (Vorwärtsmodus) 

Zusammenfassend  bleiben  folgende  Punkte  zu  bedenken: 

•  Beim  Laufzeitvergleich  zwischen  einem  generierten  und  durch  einen  Program- 
mierer implementierten  Programm,  ist  -  abhängig  von  der  Erfahrung  des  Ent- 
wicklers -  Letzteres  oft  schneller.  Dies  ist  jedoch  nur  für  relativ  einfache  Funk- 
tionen möglich,  da  sonst  der  zeitliche  Aufwand  für  die  Implementierung  zu  stark 
ansteigt.  Bei  umfangreichen  Funktionen  muss  folglich  auf  generative  Methoden 
zurückgegriffen  werden. 

•  Werden  die  erarbeiteten  Lösungsformeln  der  vorausgegangenen  Unterpunkte 
verwendet,  ist  der  Effekt  der  numerischen  Auslöschung  zu  berücksichtigen. 

•  Bei  symbolischer  Differentiation  werden  die  Gleichungen  u.U.  sehr  umfang- 
reich, was  sich  negativ  auf  die  Programmlaufzeit  auswirken  kann.  Außerdem 
steigt  bei  sehr  großen  Formeln  die  Wahrscheinlichkeit  für  Übertragungsfehler15. 

•  Die  automatische  Differentiation  mit  SCT  kann  prinzipiell  auf  jede  Program- 
miersprache angewendet  werden.  Somit  kann  auch  älterer  Quelltext16  zum  Ein- 
satz kommen.  Da  die  Ableitungsfunktion  ausschließlich  aus  arithmetischen  Ba- 
sisoperationen aufgebaut  ist,  erzielen  Optimierungen  des  Compilers  gegenüber 
objektorientierter  Operatorüberladung  einen  messbaren  Geschwindigkeitsvor- 
teil. 


6.4    Fazit  und  weitere  Arbeiten 

Die  hier  verwendeten  Methoden  zur  Bestimmung  von  höheren  Ableitungen  durch  nu- 
merisches Differenzieren  haben  ihre  Einsetzbarkeit  gezeigt.  Diese  sollten  jedoch  nur 

I5Diese  können  beispielsweise  auftreten,  falls  Formeln  mit  wxMaxima  berechnet  werden  und  diese  in 
C++  implementiert  werden  sollen.  Bestimmte  Computeralgebrasysteme  (z.B.  MATHEMATICA)  besit- 
zen für  diese  Fälle  entsprechende  Exportfunktionen  zu  ausgewählten  Programmiersprachen. 

16ln  wissenschaftlichen  Anwendungen  sind  oft  ältere  FORTRAN  Dialekte  (z.B.  FORTRAN77)  im 
Einsatz. 
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als  Hilfsmittel  zur  Überprüfung  erarbeiteter  Lösungen  verwendet  werden.  Außerdem 
sollten  die  Ergebnisse  durch  entsprechende  Kontrollrechnungen  verifiziert  werden,  da 
hierbei  der  Effekt  der  numerischen  Auslöschung  u.U.  das  Ergebnis  ungewollt  ver- 
schlechtern kann. 

Ferner  wäre  es  hilfreich,  die  Erstellung  der  Formeln  zu  automatisieren,  da  die  Über- 
tragung der  Formeln  aus  der  MATHEMATICA- Ausgabe  in  C++-Quelltext  relativ  auf- 
wendig erscheint.  Damit  könnten  Formeln  für  höhere  Ableitungsterme  je  nach  Bedarf 
dynamisch  generiert  werden.  Eine  alternative  Möglichkeit,  auf  numerischem  Weg  hö- 
here Ableitungen  zu  berechnen,  sind  Chebyshev-Polynome17. 

Weitere  Ansätze  zur  Bestimmung  höherer  Ableitungen  bieten  die  Methoden  des  auto- 
matischen Differenzierens  (AD)  oder  der  symbolischen  Differentiation.  Welche  Me- 
thode letztendlich  am  besten  geeignet  ist,  hängt  von  der  Aufgabenstellung  und  den 
Zusatzbedingungen  ab. 


Hierzu  ist  eine  Implementierung  in  [Press07]  zu  rinden.  Den  theoretischen  Hintergrund  rindet  man 
unter  http://dlmf.nist.gOv/3.l  l#ii  (Download  am  04.08.201 1) 
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Kapitel  7 


Toolbox  :  Entwickelte  Programme  und 
Bedienkonzepte 


Schwerpunkt  des  Kapitels: 

In  diesem  Abschnitt  wird  das  Konzept  einer  Toolbox  vorgestellt.  Diese  besteht  un- 
ter Anderem  aus  Komponenten  zur  numerischen  Lösung  von  gewöhnlichen  Differen- 
tialgleichungen. Um  die  Bedienung  derartiger  Programme  zu  vereinfachen,  wird  im 
Folgenden  ein  minimaler  Satz  von  Kommandozeilenoptionen  erarbeitet.  Deren  Funk- 
tionsweise wird  mit  Beispielen  gezeigt.  Außerdem  wird  ein  Programm  zum  Vergleich 
von  multiprecision-Daten  vorgestellt,  was  besonders  beim  Vergleich  von  multiprecisi- 
on  -Daten  hilfreich  ist. 
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7.1    Phasen  der  Datenverarbeitung 


Die  Verarbeitung  von  Daten  kann  in  drei  verschiedene  Phasen  unterteilt  werden.  Diese 
sind  in  Abbildung  7.1  dargestellt  und  beschreiben  eine  idealisierte  Verarbeitungsrei- 
henfolge. 


Berechnungsphase 

Analysephase 

Aufbereitungsphase 

/ 

Abbildung  7.1:  Phasen  der  Datenverarbeitung 


•  Berechnungsphase 

In  der  Berechnungsphase  werden  die  Ergebnisse  i.d.R.  durch  ein  Computerpro- 
gramm erstellt.  In  den  vorausgegangenen  Kapiteln  wurden  fast  ausschließlich 
die  Methoden  dieser  Phase  beschrieben.  Hierzu  zählen  auch  die  verwendeten 
Bibliotheken  zur  Rechnung  mit  erhöhter  Genauigkeit. 

•  Analysephase 

In  dieser  Phase  werden  die  Daten,  welche  während  der  Berechnungsphase  ver- 
arbeitet wurden,  hinsichtlich  bestimmter  Kriterien  analysiert.  In  den  meisten 
Fälle  ist  es  erforderlich,  verschiedene  Ergebnisse  einander  gegenüberzustellen 
und  deren  Genauigkeit  zu  beurteilen.  Da  diese  Vergleiche  meist  auf  das  jeweils 
untersuchte  Problem  zugeschnitten  sind,  gibt  es  keine  frei  erhältlichen  Analyse- 
werkzeuge, die  hierfür  ohne  Vorarbeit  eingesetzt  werden  können. 

•  Aufbereitungsphase 

In  der  Aufbereitungsphase  werden  die  Daten  weiterverarbeitet,  um  das  Ergebnis 
der  Analysephase  sichtbar  zu  machen.  In  den  meisten  Fällen  wird  diesbezüg- 
lich auf  Programme  wie  gnuplot1  oder  QtiPlot2  zurückgegriffen.  Viele  dieser 
Softwarepakete  besitzen  die  Möglichkeit,  Daten  einzulesen  und  diese  innerhalb 
der  jeweiligen  Programmumgebung  zu  analysieren.  In  diesem  Zusammenhang 
ist  Vorsicht  geboten,  da  beispielsweise  im  Fall  von  gnuplot  keine  Möglichkei- 
ten vorhanden  sind,  Zahlen  mit  mehrfacher  Genauigkeit  zu  verarbeiten  bzw.  zu 
analysieren. 

Als  einleitendes  Beispiel  soll  aufgezeigt  werden,  dass  bei  der  Verarbeitung  und 
Analyse  von  Gleitkommazahlen  mit  mehrfacher  Genauigkeit  die  Ergebnisse  exakt 
überprüft  werden. 

Beispiel  7.1  für  „Verarbeitung  von  Gleitkommazahlen  mit  mehrfacher  Genauigkeit" 

In  diesem  Beispiel  wurden  zwei  Lösungen  des  ungedämpften  Duffing-Oszillators  im  Intervall 
zwischen  0  und  10  berechnet.  Eine  der  beiden  Lösungen  wurde  mit  dem  Potenzreihenintegra- 
tor3  unter  Verwendung  des  bigfloat-Datentyps  der  LiDIA-Bibliothek4  berechnet.  Diese  Lösung 

'siehe  mehr  dazu  unter  http://www.gnuplot.info/,  Download  am  05.08.201 1 

2siehe  mehr  dazu  unter  http://soft.proindependent.com/qtiplot.html,  Download  am  05.08.201 1 

3Bei  jedem  Integrationsschritt  40  Reihenterme  berechnet. 

4Die  dezimale  Genauigkeit  wurde  auf  100  signifikante  Nachkommastellen  eingestellt. 
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wird  im  Folgenden  als  fi(t)  bezeichnet.  Die  andere  Lösung  wurde  mit  Hilfe  der  analytischen 
Lösung  30.Ordnung  errechnet,  welche  ebenfalls  den  bigäoat-Datentyp  verwendet  und  folgend 
als  f2(t)  bezeichnet  wird.  Die  beiden  Ergebnisse  sind  tabellarisch  in  einer  Datei  (Resultat.txt) 
gespeichert  und  sollen  nun  analysiert  werden.  Die  Daten  sind  durch  Leerzeichen  getrennt  und 
liegen  in  folgender  Reihenfolge  zeilenweise  gespeichert  vor: 

•  tn  h{tn)  /a(tn) 
wobei  n  ein  Platzhalter  für  die  Zeilennummer  ist. 

Es  soll  nun  gezeigt  werden,  wie  mit  Hilfe  des  Programms  gnuplot  der  Unterschied  der  beiden 
Lösungen  durch  Subtraktion  der  Tabellenwerte  ermittelt  wird.  Das  Ergebnis  wird  anschlie- 
ßend in  einem  Diagramm  über  der  Zeit  aufgetragen.  Dies  kann  mit  folgendem  gnuplot-Befehl 
durchgeführt  werden: 

•  plot  'Resultat.txt'  using  1  :  ($(2)  -  $(3)) 

"  v  ' 

spaltenweise  Subtraktion  der  beiden  Ergebnisse 

Das  Resultat  der  Ausgabe  ist  in  Abb.  7.2  dargestellt. 

i  i  1  1  1  ,  ,  ,  1  1  1  1 


-0.5  - 


01234567B9  10 

t 

Abbildung  7.2:  Auswirkungen  unzureichender  dezimaler  Genauigkeit  von  gnuplot 

Der  tatsächliche  Unterschied  der  beiden  Lösungen  ist  in  Abb.  7.3  dargestellt.  Um  dieses  Re- 
sultat zu  erhalten,  wurden  die  beiden  unterschiedlichen  Lösungen  mit  Hilfe  eines  zusätzlichen 
Hilfsprogramms  (  s.  Abschnitt  7.1.1  ),  welches  mit  mehrfacher  Genauigkeit  rechnen  kann,  vor- 
verarbeitet. Dieses  Beispiel  zeigt  die  Relevanz  und  den  Bedarf  an  Werkzeugen  dieser  Art.  Es 
existiert  bereits  das  Programm  numdifl5  auf  Basis  der  GNU -MP -Bibliothek,  welches  den  Un- 
terschied zweier  Dateien  mit  Hilfe  beliebiger  Genauigkeit  ermitteln  kann.  In  Fällen,  in  welchen 
die  Daten  in  unterschiedlichen  Dateien  gespeichert  sind,  ist  dies  hilfreich.  Jedoch  müssen  im 
vorliegenden  Beispiel  durch  Duplizieren  der  Datei  und  anschließender  Manipulation  der  Da- 
ten die  Ergebnisse  angepasst  werden,  was  umständlich  und  fehleranfällig  erscheint.  Deshalb 
wurde  das  Programm  simple_mp_üle_compare  entwickelt,  welches  in  dieser  Situation  Abhilfe 
schafft  (siehe  dazu  Abschnitt  7.1.1). 

5  siehe  mehr  dazu  unter  http://www.nongnu.org/numdiff/,  Download  am  01.02.201 1 
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Abbildung  7.3:  Unterschied  der  beiden  berechneten  Lösungen 

7.1.1    Entwicklung  eines  Programms  zur  Vorverarbeitung  von  Daten  mit 
hoher  Genauigkeit 

Wie  im  vorausgegangenen  Abschnitt  erwähnt,  fehlt  derzeit  ein  Programm  zur  Vor- 
verarbeitung von  Mess-  bzw.  Simulationsdaten,  welche  mit  mehrfacher  Genauigkeit 
erstellt  wurden.  Aus  diesem  Grund  wurde  für  diesen  Zweck  ein  derartiges  Programm- 
system6 entwickelt.  Hierzu  sei  kurz  der  Funktionsumfang  des  Programms  dargestellt: 

•  Der  Vergleich  der  Werte  zweier  ASCII7-Dateien,  welche  numerische  Werte  in 
Tabellenform  speichern  und  durch  Leerzeichen  (oder  Tabulatorzeichen)  getrennt 
sind,  wird  ermöglicht. 

•  Außerdem  ist  es  möglich,  die  Spalten  innerhalb  einer  Datei  auf  identische  Art 
und  Weise  zu  vergleichen. 

•  Der  Vergleich  erfolgt  durch  Bildung  des  absoluten  Fehlers8  jeweils  zweier  Werte 
einer  bestimmten  Spalte  (frei  wählbar)  der  entsprechenden  Datei. 

•  Die  dezimale  Genauigkeit  zur  Berechnung  des  absoluten  Fehlers  ist  frei  wählbar. 
Hierbei  wird  auf  die  LiDIA-Bibliothek9  zurückgegriffen. 

•  Zusätzlich  werden  Kommentarzeilen  in  den  zu  verarbeiteten  Dateien  ignoriert. 
Das  Symbol,  welches  einen  Kommentar  einleitet,  ist  frei  wählbar. 

6Das  Programm  trägt  den  Namen  simple_mp_ßle_compare. 

7Dies  ist  eine  Zeichenkodierung,  bei  der  jedem  Zeichen  ein  Bitmuster  von  7  Bit  zugeordnet  ist.  Dies 
ist  die  amerikanische  Version  des  Zeichensatzes.  Das  europäische  Pendant  hierzu  ist  ISO-646. 
8definiert  in  Abschnitt  2.1.1 
'siehe  dazu  [LiDIA] 
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•  Ferner  ist  es  möglich,  zu  jeder  der  verglichenen  Spalten  eine  zusätzliche  Spalte 
hinzugenerieren  zu  lassen,  welche  den  kumulativen  Fehler  enthält. 

In  Abbildung  7.4  ist  die  Arbeitsweise  von  simple_mp_üle_compare  schematisch  dar- 
gestellt. Hierbei  wurde  eine  Anwendung  gewählt,  bei  der  zwei  Dateien  verwendet  wer- 
den (file  1,  file  2).  Welche  Spalten  verarbeitet  werden  sollen,  kann  dem  Programm  in 
Form  von  Befehlen  auf  der  Linux-Kommandozeile  (  )  mitgeteilt  werden.  Damit 

wird  das  Programm  für  die  jeweilige  Aufgabenstellung  konfiguriert.  In  dem  hier  ge- 
wählten Beispiel  soll  aus  der  ersten  Datei  (file  1)  die  Spalte  mit  dem  Index  0  in  die 
Ausgabedatei  übernommen  werden.  Außerdem  soll  aus  der  ersten  Datei  die  Spalte  mit 
dem  und  aus  der  zweiten  Datei  die  Spalte  mit  dem  Index  2  verwendet  werden, 

um  den  absoluten  Fehler  mitzubestimmen.  Die  dabei  verwendete  Genauigkeit,  welche 
und  wie  viele  Spalten  verwendet  werden,  kann  in  den  definiert  werden. 


2  3  4  ...  0  1   2  3  4... 


\A7 


options 


si  m  pl  e_m  p_f  i  I  e_com  pa  re 


Output  file 


Abbildung  7.4:  Das  Arbeitsprinzip  des  Programms  simple_mp_file_compare  am  Bei- 
spiel von  zwei  Eingabedateien 


Beispiel  7.2  für  „Berechnung  des  absoluten  Fehlers  mit  simple _mp _ßle_compare" 

Um  die  Leistungsfähigkeit  von  simple_mp_file_compare  unter  Beweis  zu  stellen,  wird  das  vor- 
ausgegangene Beispiel  aufgegriffen.  Darin  wurden  zwei  Lösungen  des  ungedämpften  Duffmg- 
Oszillators  im  Intervall  zwischen  0  und  10  berechnet.  Eine  der  beiden  Lösungen  wurde  mit  dem 
Potenzreihenintegrator10  unter  Verwendung  des  bigfloat-Datentyps  der  LiDIA-Bibliothek11  be- 
rechnet. Die  zweite  Lösung  wurde  mit  Hilfe  der  analytischen  Lösung  30. Ordnung  errechnet, 

'"Diesbezüglich  werden  bei  jedem  Integrationsschritt  40  Reihenterme  berechnet. 

"Die  dezimale  Genauigkeit  wurde  hierbei  auf  100  signifikante  Nachkommastellen  eingestellt. 
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wofür  ebenfalls  der  big float- Datentyp  genutzt  wurde.  Die  beiden  Ergebnisse  sind  in  einer  Datei 
(Resultat.txt),  tabellarisch  abgespeichert.  Sollen  die  Daten  nun  analysiert  werden,  so  ist  in  vie- 
len Fällen  der  absolute  Fehler  ein  hilfreiches  Kriterium.  Hierzu  wird  simple_mp_file_compare 
verwendet,  um  aus  der  zweiten  Spalte  (Index  1)  und  dritten  Spalte  (Index  2)  derselben  Datei 
den  absoluten  Fehler  aller  Messwerte  zu  berechnen.  Außerdem  wird  die  erste  Spalte  (Index  0) 
in  die  Ausgabedatei  (Output.txt)  übernommen.  Zusätzlich  wird  der  kumulative  absolute  Feh- 
ler in  die  vierte  Spalte  (Index  3)  der  Ausgabedatei  (Output.txt)  eingefügt.  Da  die  Ausgangs- 
daten auf  100  signifikante  Dezimalstellen  genau  gerechnet  werden,  wird  für  die  Weiterver- 
arbeitung die  interne  Genauigkeit  auf  200  Dezimalstellen  eingestellt.  Der  benötigte  Befehl 
auf  der  Linux-Kommandozeile  ist  in  Listing  7.1  dargestellt.  Zur  Konfiguration  besitzt  sim- 

[CLI]  Command  Line  ple_mp_file_compare  ein  CLI .  Die  wichtigsten12  Optionen  werden  hier  kurz  erklärt: 
Interface 

•  —fl  =[ Dateiname],— /2  —[Dateiname] 

Mit  dieser  Option  können  die  Eingabedateien  festgelegt  werden.  Falls  nur  eine  Datei 
verwendet  werden  soll  und  darin  einige  Spalten  verarbeitet  werden  sollen,  ist  für  beide 
Optionen  derselbe  Dateiname  anzugeben. 

•  —kl  =[  Spaltenindex  ],—k2  —[Spaltenindex] 

Hier  können  die  Spaltenindizes  der  jeweiligen  Dateien  angegeben  werden,  welche  in  die 
Ausgabedatei  mit  übernommen  werden.  Sollen  mehrere  Spalten  aus  einer  Datei  über- 
nommen werden,  dann  sind  die  Indizes  mit  Kommas  zu  trennen. 

•  — cl  =/ Spaltenindex  ],—c2  —[Spaltenindex] 

Durch  Angabe  der  Spaltenindizes  können  die  Spalten  bestimmt  werden,  aus  denen  der 
absolute  Fehler  gerechnet  wird.  Mehrere  Spaltenindizes  werden  durch  Komma  getrennt 
angegeben.  Bei  dieser  Option  ist  die  gleiche  Anzahl  der  Spaltenindizes  für  beide  Optio- 
nen erforderlich,  andernfalls  bricht  das  Programm  mit  einer  Fehlermeldung  ab. 

•  -append-cumulative-col 

Wird  diese  Option  verwendet,  dann  wird  neben  jeder  der  Spalten,  bei  denen  ein  absolu- 
ter Fehler  berechnet  wird,  eine  zusätzliche  Spalte  generiert.  Diese  enthält  die  Werte  des 
absoluten,  kumulativen  Fehlers. 

•  —l[Multiprecision-Bibliothek] 

Mit  dieser  Option  kann  die  zur  Berechnung  verwendete  Multiprecision-Bibliothek  aus- 
gewählt werden.  In  diesem  Beispiel  wurde  die  LiDIA-Bibliothek  ausgewählt. 

•  —p[Anzahl  Dezimalstellen ] 

Diese  Option  funktioniert  nur  in  Verbindung  mit  der  Option  zur  Definition  einer  be- 
stimmten Multiprecision-Bibliothek  (—1).  Damit  kann  die  Anzahl  signifikanter  Nach- 
kommastellen, welche  man  zur  Berechnung  verwendet,  angegeben  werden. 

•  —o  =[Name  der  Ausgabedatei] 

Hiermit  kann  der  Name  bzw.  der  Pfad  der  Ausgabedatei  angegeben  werden. 


Eine  vollständige  Liste  aller  Optionen  ( inkl.  Beispiel)  kann  mit  dem  Linux-Kommandozeilenbefehl 
./simple_mp_file_compare  -h  angezeigt  werden. 


7.1  Phasen  der  Datenverarbeitung 
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Abbildung  7.5:  Absoluter  kumulativer  Fehler  zweier  Lösungen  der  ungedämpften 
Duffing-Oszillatorgleichung 


1  .  /  simple_mp_file_compare  — f  1  =  Result  .  t x t  —  f2  =  Result  .  txt 

2  —  kl=0  — cl=l  — c2=2  — append— cumulative  — col 

3  — lLiDIA  -p200  -o=Output  .  txt 


Listing  7.1:  Aufruf  von  simple_mp_file_compare 


7.1.2    Weiterentwicklung  von  simple_mp_file_compare 

Um  den  Vergleich  von  Dateien  und  somit  die  Verwendung  von  simple_mp_nie_compare 
benutzerfreundlicher  zu  gestalten,  wurde  ein  Konzept  einer  graphischen  Benutzerober- 
fläche entworfen.  Das  GUI  basiert  auf  der  wxWidgets  ^-Programmbibliothek.  Dies  ist 
eine  Open-Source -Programmbibliothek,  mit  der  es  möglich  ist,  ein  Programm  auf  ei- 
ner bestimmten  Plattform  (z.B.  Linux)  zu  entwickeln  und  es  später  auf  einer  anderen 
Betriebssystemplattform  (z.B.  Windows)  zu  verwenden.  Das  Design  wurde  mit  dem 
RAD-Programm  wxFormBuilder14  erstellt.  In  Abbildung  7.6  ist  das  entworfene  De- 
sign dargestellt. 

Im  Folgenden  werden  die  Grundfunktionen  des  Designentwurfs  erläutert: 


[GUI]  Graphical  User 
Interface 


[RAD] 

Application 

Development 


Rapid 


13  siehe  mehr  dazu  auf  der  Webseite  des  Projekts:  http://www.wxwidgets.org,  Download  am  13.10.201 1 
14siehe  mehr  dazu  auf  der  Webseite  des  Projekts:  http://www.wxformbuilder.org,  Download  am 
13.10.2011 
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Decimal  Precision  20 


File  1  L/results/Filel.txt 


File  2  |.,/results/Rl!e2.txt 


y 


Filel  iki  Rle2  I  Result 


ignore 


,  compare  ;  keep 


_L 


3  6470E»0Sf 
B,B097E+09f| 
B,7594E+0Bf| 
7,0191  E+07f| 
1.8«S3E-!0f' 


1.4023E*10f 


2.501 6E+0af 
4,271 0E+09f 
2.2634E*09I 
8.78S7E*09f 
E,6134E+09f 
1.9662E+10f 
6.6126E+09f 
1.0737E-H0I 
2.1837E+10t 


3.3879E+IOI  l,7495E+10f 

3.3181E+10T:  2.3985E+10f 


l,5747E+10f  4.1411E+10f 


^  l  Compare 


Legend 


(2)  useraction 
|    |  userfeedback 


Abbildung  7.6:  Grafische  Benutzeroberfläche  von  wxFloatCompare 


1.  Hier  kann  der  Benutzer  die  Anzahl  signifikanter  Nachkommastellen  eingeben, 
welche  zur  Berechnung  verwendet  werden. 

2.  Drückt  der  Benutzer  auf  einen  der  beiden  Buttons,  so  kann  die  jeweilige  Einga- 
bedatei geladen  werden.  Der  anschließend  verwendete  Pfad  wird  links  daneben 
angezeigt.  Dort  ist  es  außerdem  möglich,  den  Pfad  direkt  einzugeben. 

3.  In  den  ersten  zwei  Reitern  wird  der  Inhalt  der  jeweils  geladenen  Dateien  darge- 
stellt. Diese  tragen  die  Beschriftung  File  1  und  File  2.  Im  dritten  Reiter  werden 
die  Ergebnisse  nach  der  Verarbeitung  angezeigt. 

4.  In  dieser  Zeile  erhält  der  Benutzer  zu  jeder  Zeile  einer  geladenen  Datei  die  Mög- 
lichkeit zwischen  drei  Optionen  auszuwählen: 

•  ignore:  Diese  Spalte  bei  soll  bei  der  Verarbeitung  ignoriert  werden.  Hat 
der  Benutzer  diese  Option  gewählt,  dann  werden  die  Werte  in  hellgrau 
eingefärbt. 

•  keep:  Die  Werte  dieser  Spalte  werden  in  die  Ausgabe  übernommen  und 
nicht  zur  Verarbeitung  verwendet.  Ist  diese  Option  eingestellt,  so  werden 
die  Werte  dieser  Spalte  in  blau  eingefärbt. 

•  compare:  Mit  dieser  Option  wird  eine  Spalte  zum  Vergleich  ausgewählt. 
Ist  diese  Option  aktiv,  so  werden  die  Werte  dieser  Spalte  grün  eingefärbt. 

5.  Hiermit  kann  der  Benutzer  die  Berechnung  beginnen,  nachdem  er  die  jeweiligen 
Spalten  zum  Vergleich  ausgewählt  hat. 


7.2  Programme  zur  Lösung  gewöhnlicher  Differentialgleichungen 
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6.  Ist  die  Berechnung  abgeschlossen,  dann  können  die  Ergebnisse  in  einer  Datei 
gespeichert  werden. 

7.  In  dieser  Anzeige  erhält  der  Benutzer  eine  Rückmeldung  des  Programms,  wel- 
che Daten  geladen  sind  und  welche  Spalten  er  momentan  ausgewählt  hat. 

8.  Hier  wird  dem  Benutzer  angezeigt,  welche  Dateien  bzw.  Dateipfade  gerade  ge- 
laden sind. 

7.2    Programme  zur  Lösung  gewöhnlicher  Differentialglei- 
chungen 

Im  Rahmen  dieser  Arbeit  wurden  eine  ganze  Reihe  verschiedener  Aufgabenstellun- 
gen untersucht.  Zu  diesem  Zweck  wurden  speziell  dafür  angepasste  Programme  ent- 
wickelt, welche  auf  die  jeweils  geforderte  Aufgabenstellung  zugeschnitten  sind.  Um 
diese  Programme  zu  bedienen  gibt  es  i.d.R.  eine  Vielzahl  verschiedener  Konfigura- 
tionsmöglichkeiten. Im  folgenden  Abschnitt  werden  diese  kategorisiert  und  anschlie- 
ßend definiert.  Jedes  der  entwickelten  Programme  besitzt  somit  einen  beschränkten 
Satz  an  Basisoptionen.  Dadurch  wird  die  Nutzerfreundlichkeit  der  jeweiligen  Pro- 
gramme entscheidend  vereinfacht  und  der  Funktionsumfang  auf  ein  erträgliches  Mi- 
nimum gesenkt.  Ferner  werden  die  jeweils  verwendeten  Kommandozeilenbefehle  an 
den  GNU-Standard15  für  Kommandozeilenbefehle  angelehnt. 

7.2.1    Kategorisierung  der  Einstellungsmöglichkeiten  eines  Programms 
zur  Lösung  von  Bewegungsproblemen 

Hier  sollen  zunächst  die  Eingabeoptionen  eines  allgemeinen  Programms  zur  Lösung 
eines  nicht  näher  spezifizierten  Bewegungsproblems  betrachtet  werden.  Eine  Submen- 
ge  der  hierfür  benötigten  Eingabeoptionen  ist  stichpunktartig  in  Abb.  7.7  abgebildet. 
Diese  können  in  folgende  Hauptkategorien  unterteilt  werden: 

•  Numerische  Einstellungen 

Diese  beziehen  sich  auf  den  jeweils  zur  Berechnung  verwendeten  Datentyp.  Ent- 
scheidet man  sich  für  einen  bestimmten  Datentyp,  bei  dem  beispielsweise  die 
dezimale  Genauigkeit  frei  wählbar  ist,  so  muss  diese  ebenfalls  angegeben  wer- 
den, d.h.  diese  Option  hängt  von  der  anderen  ab.  Wird  andererseits  ein  Basisda- 
tentyp (z.B.  double)  verwendet,  bei  dem  die  Genauigkeit  vorgegeben  ist,  dann 
ist  diese  Option  nutzlos. 

•  Integrationseinstellungen 

Bei  den  Einstellungen  zur  Integration  können  sowohl  die  Start,  als  auch  die  End- 
epoche angegeben  werden.  Außerdem  kann  die  Schrittweite  der  Integration  und 
deren  Anzahl  festgelegt  werden. 

•  Integratorauswahl  und  Konfiguration 

Bei  dieser  Kategorie  kann  der  zur  Berechnung  verwendete  Algorithmus  gewählt 

15 siehe  mehr  dazu  in  der  Onlinedokumentation  unter  http://www.delorie.com/gnu/docs/GNU/standards_18.html, 
Download  am  14.10.2011 
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Abbildung  7.7:  Einstellungsmöglichkeiten  eines  Programms  zur  Lösung  von  Bewe- 
gungsproblemen 

werden.  Ist  ein  bestimmter  Algorithmus  ausgewählt,  so  können  i.d.R.  zusätz- 
liche Einstellungen  vorgenommen  werden.  Wird  beispielsweise  der  Potenzrei- 
henintegrator (PowSerlnt)  verwendet,  dann  muss  die  Anzahl  der  Potenzreihen- 
koeffizienten angegeben  werden.  Folglich  werden  auch  hier  Optionen  benötigt, 
welche  von  den  anderen  implizit  abhängig  sind. 

•  Ausgabe 

Hierbei  kann  die  Zieldatei  und  das  jeweilige  Ausgabeformat  angegeben  werden. 

•  Anfangswerte  und  Parameter  der  Differentialgleichung 

Aus  einer  Konfigurationsdatei  werden  sowohl  die  Anfangswerte  zur  Integration, 
als  auch  die  Parameter  der  jeweiligen  Differentialgleichung  beim  Programmstart 
abgelesen. 

Somit  können  folgende  Kommandozeilenoptionen  definiert  werden: 

•  -conüg-ßle=[Pfad  zur  Konfigurationsdatei] 

Durch  Angabe  der  Konfigurationsdatei  werden  die  Anfangswerte  und  die  Pa- 
rameter der  Differentialgleichung  vor  Beginn  der  Rechnung  in  das  Programm 
geladen.  Es  wäre  prinzipiell  möglich,  Angaben  ebenfalls  via  Kommandozeilen- 
optionen in  das  Programm  einzuspeisen.  Hier  erschient  es  praktikabel,  diese 
Parameter  in  einer  Datei  abzulegen,  da  in  den  meisten  Fällen  eine  Aufgaben- 
stellung mit  unterschiedlichen  numerischen  Genauigkeiten  bzw.  Algorithmen 
untersucht  wurde.  Beispielhaft  ist  in  Listing  7.2  die  Konfigurationsdatei  zur  Be- 
rechnung des  Duffing-Oszillators  angegeben.  Das  hierfür  verwendete  Datenfor- 

[xml]     EXtensibie  mat  ist  XML-ähnlich  und  benötigt  zum  Lesen  der  Datei  einen  speziell  dafür  ent- 

Markup Language 
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wickelten  Konfigurationsparser  .  Im  Allgemeinen  ist  die  Konfigurationsdatei  in 
zwei  Abschnitte  unterteilt.  Im  Abschnitt  InitialValues  werden  die  Anfangs  werte 
zur  Integration  festgelegt.  Dabei  bezeichnet  der  Parameter  x  den  Anfangsort  und 
der  Parameter  vx  die  Anfangsgeschwindigkeit.  Im  Abschnitt  Parameter  werden 
die  Konstanten,  welche  die  Bewegung  des  Duffing-Oszillators  beschreiben,  de- 
finiert. 


1 

<ODE> 

2 

<InitialValues> 

3 

Name  =  Experimentl 

4 

x        =  1 

5 

vx  =0 

6 

</  Initial  Values> 

7 

<Parameter> 

8 

Delta     =  1.0e-2 

9 

Omega     =  1 

10 

Damped  =  false 

11 

Gamma    =   1 . 0  e  —2 

12 

<l  Parameter> 

13 

</ODE> 

Listing  7.2:  Konfigurationsdatei  für  den  Duffing-Oszillator  (Dufßng.conf) 

•  -üoat-type=[Name  des  Datentyps] 

Mit  dieser  Option  kann  der  zur  Berechnung  verwendete  Datentyp  festgelegt  wer- 
den. Wird  ein  Datentyp  mit  frei  wählbarer  Anzahl  signifikanter  Dezimalstellen 
verwendet,  dann  ist  es  erforderlich,  diese  mit  Hilfe  der  Option  -precision=  fest- 
zulegen. 

•  -precision=[Anzahl  signifikanter  Nachkommastellen] 

Mit  dieser  Option  kann  die  Anzahl  der  signifikanten  Dezimalstellen  festgelegt 
werden.  Diese  ist  jedoch  nur  bei  Datentypen  gültig,  bei  denen  die  Genauigkeit 
eingestellt  werden  kann,  d.h.  bei  den  primitiven  Datentypen  üoat,  double  und 
long  double  hat  diese  Option  keine  Wirkung. 

•  -integration-stepnumber-[Anzahl  der  Integrationsschritte] 

Die  Anzahl  der  Integrationsschritte  kann  mit  dieser  Option  festgelegt  werden. 
Hierbei  ist  darauf  zu  achten,  dass  Integerzahlen  verwendet  werden. 

•  -integration-stepsize=[Integrationsschrittweite] 

Hier  kann  die  Integrationsschrittweite  definiert  werden.  Ist  diese  beispielsweise 
auf  den  Wert  1.5  eingestellt  (-integration-stepsize=1.5),  dann  erfolgt  die  Inte- 
gration in  1.5-er  Schritten. 

•  -integration-start=[Startzeitpunkt  (Epoche)  ] 

Die  Startepoche  der  Integration  kann  mit  Hilfe  dieser  Option  festgelegt  werden. 

16Dieser  wurde  am  Geodätischen  Observatorium  in  Wettzell  entwickelt.  Mehr  Informationen  zu  diesen 
und  anderen  Komponenten  dieser  Art  sind  auf  folgender  Webseite  zu  finden:  http://econtrol-software.de/ 
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Dabei  ist  zu  beachten,  dass  der  Zeitpunkt,  zu  dem  die  Integration  beendet  wird 
(tend),  wie  folgt  berechnet  werden  kann: 

tend  =  t start  +  n  *  h  (7.2. 1) 

Wobei  n  ein  Platzhalter  für  die  Anzahl  der  Integrationsschritte  und  h  ein  Platz- 
halter für  die  Integrationsschrittweite  ist. 

•  -integrator-type=[Name  des  Integrators] 

Die  Differentialgleichung  kann  mit  unterschiedlichen  Lösungsverfahren  gelöst 
werden.  Hier  kann  eines  der  folgenden  Lösungsverfahren  ausgewählt  werden: 

-  BS: 

Burlisch-Stoer- Verfahren 

-  RK2,RK3,RK4,RK8,RK10: 

Runge-Kutta- Verfahren  unterschiedlicher  Ordnung 

-  MMID: 

Modified-Midpoint  Methode 

-  GJ4: 

Gauss- Jackson  (4.  Ordnung) 

-  DOPRI: 

Dormand-Prince  Methode 

-  SG: 

Shampine  Gordon  -  Verfahren 

-  POWSERINT: 

Potenzreihenintegrationsverfahren 

-  SYMP4,SYMP6,SYMP8: 

Symplektische  Verfahren  unterschiedlicher  Ordnung 

-  LFROG: 

Leapfrog-Verfahren 

•  -integrator-abstol=[Absolute  Fehlertoleranz] 

Wird  ein  Verfahren  mit  adaptiver  Schrittweitensteuerung  verwendet,  so  ist  au- 
ßerdem die  Angabe  einer  absoluten  Fehlertoleranz  nötig.  Mit  dieser  Option  kann 
diese  dem  Programm  mitgeteilt  werden. 

•  -integrator-coeffs=[Anzahl  Potenzreihenkoeffizienten] 

Wird  der  Potenzreihenintegrator  ausgewählt,  dann  kann  mit  dieser  Option  die 
Anzahl  der  verwendeten  Potenzreihenkoeffizienten  festgelegt  werden. 

•  -output-ßle=[Pfad  zur  Ausgabedatei] 

Soll  das  Ergebnis  in  eine  bestimmte  Textdatei  geschrieben  werden,  dann  kann 
diese  Option  verwendet  werden.  Wird  auf  diese  verzichtet,  dann  wird  das  Er- 
gebnis auf  die  Standardausgabe  geschrieben. 
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Beispiel  7.3  für  „Integration  des  Lorenz-Attraktors" 

Hier  soll  beispielhaft  der  Lorenz-Attraktor11  mit  Hilfe  des  Burlisch-Stoer-Integrators  gelöst 
werden.  Die  Lorenz-Gleichung  besteht  aus  drei  gekoppelten,  nichtlinearen  Differentialglei- 
chungen der  Form: 


dx       .  . 

^=x(b~z)-y  (7.2.2) 
dt 

dz 

—  =  xv  —  cz 
dt  y 


Wobei  die  Variablen  a,  b  und  c  als  Konstanten  betrachtet  werden.  Zur  Integration  werden  die 
Werte  a  —  10,6  =  28  und  c  =  |  gesetzt.  Als  Anfangswerte  werden  die  Werte  x  =  10, y  =  20 
und  z  —  30  verwendet.  Um  diese  Aufgabenstellung  zu  lösen,  wird  auf  die  oben  definierten 
Kommandozeilenparameter  zurückgegriffen  und  das  Ergebnis  in  der  Datei  LorenzBS.txt  ge- 
speichert. 

Somit  muss  das  Programm  ( IntegrateLorenz)  mit  bestimmten  Kommandozeilenparametern  auf- 
gerufen werden.  Diese  sind  in  Listing  7.3  angegeben.  In  Zeile  1  wird  erst  das  Programm  aufge- 
rufen und  dann  die  Konfigurationsdatei1^  angegeben.  Diese  enthält  die  Anfangswerte  und  die 
Konstanten  zur  Berechnung  des  Lorenz-Attraktors. 


LorenzBS.txt   


z 


Abbildung  7.8:  Graphische  Darstellung  des  Lorenz-Attraktors 


Mehr  Informationen  findet  man  dazu  unter  [Schuster05]  (ab  Seite  109). 
Die  Datei  Lorenz.conf  ist  im  Anhang  F.  1  auf  Seite  217  zu  finden. 
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1  .  . / bin  /  IntegrateLorenz     — conf  ig  —  f i  1  e  =../ conf / Lorenz . conf 

2  — f  loat  — type=Xdouble 

3  — integrator — type=BS 

4  — i  n  te  gr  at  or  — ab  s  t  ol  =  1  .Oe  — 15 

5  — i n t egr a t i on — s t ar t =0 

6  — i  nt  egr  ati  on  — s  tep  s  i  z  e  =0.00 1 

7  — integration  — stepnumber  =  10000 

8  —  Output  —  f i le  =  ../samples  / LorenzBS  .  t x t 


Listing  7.3:  Kommandozeilenparameter  zur  Lösung  des  Lorenz-Attraktors 


7.2.2    Anmerkung  zum  Lorenz-Attraktor 

Die  Lorenz'schen  Differentialgleichungen  reagieren  auffällig  sensibel  auf  Veränderun- 
gen. Sogar  das  Umstellen  der  Gleichung  durch  einfaches  Ausklammern  der  Konstanten 
a  auf  der  rechten  Seite  von 

—  =  ay  -ax  (7.2.3) 

nach 

dx 

—  =  a(y  -  x)  (7.2.4) 

hat  bereits  einen  Einfluss  auf  das  Endergebnis.  Die  beiden  Ausdrücke  sind  mathema- 
tisch identisch,  jedoch  werden  sie  aufgrund  des  Rechengesetzes  (Punkt  vor  Strich) 
anders  abgearbeitet.  Infolgedessen  kann  ein  anderer  Rundungsfehler  auftreten,  der  das 
Endergebnis  verändert.  Bei  derart  eng  gekoppelten  Differentialgleichungen  ist  folglich 
Vorsicht  geboten.  Andererseits  kann  mit  diesen  Gleichungen  chaotisches  Verhalten 
nachgewiesen  werden  und  ist  folglich  für  die  mathematische  Chaostheorie  nützlich. 


7.3    Fazit  und  weitere  Entwicklungen 

In  diesem  Abschnitt  wurde  ein  Bedienkonzept  für  die  Programme  zur  Lösung  von  Be- 
wegungsproblemen auf  Basis  von  Kommandozeilenoptionen  erarbeitet.  Dieser  funk- 
tionelle Ansatz  könnte  mit  einer  graphischen  Benutzeroberfläche  deutlich  komforta- 
bler gestaltet  werden.  Dazu  könnte,  wie  schon  bei  wxFloatCompare,  die  plattform- 
unabhängige Klassenbibliothek  wxWidgets19  oder  Qt20  verwendet  werden.  Entschei- 
dend bei  einer  derartigen  Entwicklung  ist,  dass  aus  Sicht  der  Informatik  die  Trennung 
[GUi]  Graphical  User  zwischen  eigentlicher  Berechnung  und         gewahrt  bleibt,  da  sonst  die  Wartbar- 
interface keit  des  Quellcodes  mit  zunehmender  Funktionalität  nicht  mehr  gewährleistet  ist.  Au- 
ßerdem wäre  dadurch  eine  Client/Server  Architektur  möglich,  bei  der  die  graphische 
Benutzeroberfläche  nicht  zwingend  auf  demselben  Rechner  betrieben  werden  muss21. 
Dies  kann  durch  Spezifikation  von  Schnittstellenfunktionen  gewährleistet  werden,  was 
[idl]        Interface  i.d.R.  mit  Hilfe  einer  IDL22  realisiert  wird.  Hierbei  werden  die  Schnittstellenfunk- 
Descnption  Language  tjonen  m  abstrakter  Form  definiert  und  einem  Softwaregenerator  übergeben,  der  für 

"Siehe  mehr  dazu  unter  http://wxwidgets.org,  Download  am  19.10.201 1 
2CSiehe  mehr  dazu  unter  http://qt.nokia.com/products/,  Download  am  19. 10.201 1 
21  Siehe  mehr  dazu  unter  [Neidhardt08] 
22Bekannte  Repräsentanten  hierfür  sind  CORBA  und  SOAP. 
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Abbildung  7.9:  Unterteilung  zwischen  Anwendung  und  Darstellung 


Client  und  Server  die  jeweiligen  Funktionen  generiert.  Werden  ausschließlich  diese 
Funktionen  zur  Kommunikation  zwischen  den  beiden  Teilen  verwendet,  so  ist  diese 
Trennung  gewährleistet.  Darüber  hinaus  können  die  beiden  Programmteile  (  und 
Berechnung)  von  unterschiedlichen  Personen  betreut  werden,  was  die  Weiterentwick- 
lung längerfristig  fördern  würde. 

Außerdem  wäre  es  hilfreich,  die  numerischen  Ergebnisse  direkt  auf  graphischem  Weg 
auswerten  zu  können.  Aktuell  werden  die  errechneten  Daten  erst  in  eine  ASCII-Datei 
geschrieben  und  anschließend  mit  einem  Hilfsprogramm  (z.B.  gnuplot)  visualisiert. 
Hier  könnte  das  C++-Interface  zum  gnupiot-Programm  (gnuplot-cpp23)  einen  nützli- 
chen Beitrag  leisten.  Dies  ist  eine  Erweiterung  zum  gnupiot-Programm  mit  direkter 
C++-Sprachunterstützung.  Damit  können,  ohne  den  Umweg  über  ASCII-Dateien,  die 
jeweiligen  Daten  direkt  graphisch  visualisiert  und  bei  Bedarf  in  ein  Bild  exportiert 
werden. 


siehe  mehr  dazu  unter  http://code.google.eom/p/gnuplot-cpp/,  Download  am  19. 10.201 1 
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Kapitel  8 


Anwendungsbeispiele  zur  Integration  von 
Bewegungsproblemen 


Schwerpunkt  des  Kapitels: 

Aufgrund  der  immer  größer  werdenden  Ansprüche  hinsichtlich  der  Genauigkeit  bei 
der  Beobachtung  von  Laserentfernungsmessungen  zu  Satelliten  und  zum  Mond,  wer- 
den konsequenterweise  die  Anforderungen  an  die  numerischen  Verfahren  ebenfalls 
erhöht.  In  diesem  Abschnitt  sollen  sowohl  die  Leistungsfähigkeit,  als  auch  die  Schwä- 
chen heutiger  Verfahren  exemplarisch  aufgezeigt  werden.  Hierzu  werden  zwei  aus  der 
Praxis  bekannte  Anwendungsfälle  aufgegriffen  und  das  bei  der  numerischen  Berech- 
nung anfallende  Fehlerbudget  betrachtet.  Das  jeweilig  ermittelte  Fehlerbudget  gilt  als 
Qualitätskriterium  zum  Vergleich  der  unterschiedlichen  Berechnungsmethoden. 

•  Im  ersten  Anwendungsfall  wird  die  rechnerische  Genauigkeit  zweier  sich  ver- 
folgender Satelliten,  wie  es  beispielsweise  bei  der  GRACE-Mission  der  Fall  ist, 
mit  verschiedenen  Methoden  simuliert  und  untersucht. 

•  Im  zweiten  praktischen  Beispiel  wird  mit  Hilfe  des  Programms  EPHEMER  eine 
Ephemeride  der  geozentrischen  Mondbahn  über  einen  Zeitraum  von  32  Jahre 
hinweg  berechnet  und  auf  ihre  Genauigkeit  untersucht. 
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8.1    Berechnung  der  Abstände  zwischen  GRACE-A  und  -B 
Satelliten 

In  diesem  Abschnitt  sollen  die  Satellitenbahnen  der  GRACE-Mission  simuliert  wer- 
den. Hierzu  werden  verschiedene  numerische  Integrationsverfahren  eingesetzt.  Die  je- 
weiligen Berechnungen  werden  zunächst  mit  herkömmlicher,  dezimaler  Genauigkeit 
und  anschließend  mit  erhöhter  Genauigkeit  durchgeführt. 


Abbildung  8.1:  GRACE-A  und  B  Satelliten  im  Erdorbit 


Mit  Hilfe  dieser  Vorgehensweise  können  numerische  Effekte  bzw.  das  Fehlerbud- 
get der  jeweils  ungenaueren  Berechnung  sichtbar  gemacht  werden. 

8.1.1    Die  GRACE-A  und  B  Mission 

Der  Name  GRACE  ist  ein  Akronym,  das  für  Gravity  Recovery  And  Climate  Experiment 
steht.  Diese  deutsch-amerikanische  Satellitenmission  hat  das  Ziel,  das  Gravitationsfeld 
der  Erde  in  hoher  räumlicher  und  zeitlicher  Auflösung  zu  bestimmen.  Die  Mission  be- 
steht aus  zwei  identischen  Satelliten,  welche  sich  in  einem  polaren  Orbit  auf  einer 
Höhe  von  500  Kilometer  mit  einem  Abstand  von  230  Kilometer  verfolgen.  Abb.  8.11 
illustriert  das  GRACE-Satellitenpaar. 

Die  beiden  Satelliten  bestimmen  mit  Hilfe  eines  an  Bord  befindlichen  GPS -Empfängers 
ihre  momentane  Position.  Ferner  wird  kontinuierlich  der  Abstand  der  beiden  Satelliten 
durch  ein  Mikrowellenverfahren  bestimmt.  Anhand  der  gesammelten  Information  ist 
es  möglich,  ein  Modell  des  Gravitationsfeldes  der  Erde  zu  bestimmen.  Mehr  Informa- 


1  Dieses  Bild  wurde  der  Webseite  der  GRACE  Mission  entliehen  http://www.csr.utexas.edu/grace/, 
Download  am  03.05.2010. 
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tionen  zu  diesem  Modell  und  der  GRACE-Mission  findet  man  auf  der  Webseite  zur 
Mission2. 

8.1.2    Anfangswerte  zur  Simulation 

Um  die  Mission  so  genau  wie  möglich  in  der  Simulation  nachzustellen,  wurden  die 
Keplerschen  Bahnelemente  in  kartesische  Startkoordinaten  umgerechnet.  Diese  sind  in 
herkömmlicher,  dezimaler  Genauigkeit  in  Tabelle  8. 1  aufgelistet.  Für  die  Berechnung 
mit  höherer  Genauigkeit  wurden  entsprechend  genauere  Anfangswerte  verwendet. 


Komponente 

GRACE-A 

GRACE-B 

Einheit 

x(t0) 

6771.358863 

6767.4414785087768080 

[km] 

y(to) 

-0. 14583562 17974367E-94 

8.1467152155126077979 

[km] 

z(to) 

-0.41 19020590424369E-93 

230.09819572516469395 

[km] 

x(t0) 

0.46723802 140296940E-96 

-0.261133431327396422 

[km/s] 

y{to) 

0.27160990850338429 

0.2714520466861765550 

[km/s] 

z(to) 

7.67142384457644789 

7.6669722925044407280 

[km/s] 

Tabelle  8.1:  Anfangswerte  von  GRACE-A  und  B 


Eine  kurze  Kontrollrechnung  soll  zeigen,  dass  die  hier  verwendeten  Anfangswerte 
zwei  Satelliten  beschreiben,  welche  sich  in  einem  Abstand  von  ca.  230  km  verfolgen. 
Um  den  Abstand  der  beiden  Satelliten  dAtB{t)  zu  einem  bestimmten  Zeitpunkt  t  zu 
berechnen,  ergibt  sich  folgender  Zusammenhang: 

dA,B(t)  =  y/{xA{t)  -  xB{t)Y  +  (yA(t)  -  yB(t))2  +  (zA(t)  -  zB{t))2  (8.1.1) 

Hierbei  ist  xA(t)  ein  Platzhalter  für  die  kartesische  X-Koordinate  des  GRACE-A- 
Satelliten  zum  Zeitpunkt  t.  Das  Einsetzen  der  Anfangswerte  aus  Tabelle  8.1  ergibt 
folgendes  Ergebnis: 

dAB(t)  =  230.2756924775842151120741618797183036804... [fem]  (8.1.2) 
8.1.3  Simulationen 

Um  die  Abstände  der  beiden  GRACE-Satelliten-Orbits  zu  berechnen,  werden  diese 
mit  unterschiedlichen  Berechnungsverfahren  ermittelt  und  die  jeweiligen  Ergebnisse 
einander  gegenübergestellt.  Ferner  wurde  die  Anzahl  der  signifikanten  Nachkomma- 
stellen variiert,  um  numerische  Effekte  der  jeweils  untersuchten  Verfahren  sichtbar  zu 
machen.  In  Abbildung  8.2  sind  die  Abstände  zwischen  GRACE-A  und  -B  in  einem 
Zeitraum  von  fünf  Stunden  aufgetragen. 


2http://www.csr.utexas.edu/grace/,  Download  am  10.10.2011 
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Abstand  von  GRACE  A  und  B 


2000  4000  6000 


10000  12000  14000  16000  18000 


Abbildung  8.2:  Abstände  der  GRACE-A  und  -B-Satelliten  über  einen  Zeitraum  von 
fünf  Stunden 


Hierbei  fällt  auf,  dass  die  Abstände  der  beiden  Satelliten,  gemessen  von  peak  to 
peak,  im  Laufe  der  Zeit  als  Folge  der  gewählten  Anfangsbedingungen  zunehmen. 
Der  maximale  Abstand  lag  bei  230.349882  Kilometer  und  der  minimale  Abstand  bei 
229.938827  Kilometer. 

Als  anisotropes  Gravitationsfeld  wurde  das  EGM96-Modell3  mit  Grad  und  Ordnung 
40  verwendet.  Durch  den  Vergleich  der  Einzellösungen,  welche  mit  unterschiedli- 
chen dezimalen  Genauigkeiten  berechnet  werden,  können  u.U.  auftretende,  numeri- 
sche Ungenauigkeiten  sichtbar  gemacht  werden.  Dabei  entsteht  beim  Vergleich  der 
unterschiedlichen  Lösungen  eine  individuelle  Fehlerkurve.  Aus  dieser  kann  sowohl 
der  Fehlerverlauf,  als  auch  die  verbleibende  Restgenauigkeit  des  Ergebnisses  abgele- 
sen werden. 

8.1.4  Abstandsdifferenzen 

Um  die  unterschiedlich  ermittelten  Abstandslösungen  (La,b  miteinander  vergleichen 
zu  können,  werden  Abstandsdifferenzen  gebildet.  Diese  sind  definiert: 

dA,B  (*)  =  \dA,B    (*)  ~dA,B    (*)l  (8-L3) 

wobei  die  hochgestellten  Indizes  bedeuten: 

•  11,12 

Bezeichnung  des  jeweils  verwendeten  Integrators. 

•  P1,P2 

Dezimale  Genauigkeit,  die  zur  Berechnung  verwendet  wurde. 


3http://cddis.nasa.gov/926/egm96/egm96.html,  Download  am  08.10.201 1 
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Somit  kann  ein  bestimmter  Abstand,  welcher  mit  dem  Runge-Kutta- Verfahren  (lO.Ord- 
nung)  bestimmt  wurde,  unter  Verwendung  eines  bestimmten  Datentyps  mit  einer  dezi- 
malen Genauigkeit  von  beispielsweise  15  signifikanten  Nachkommastellen  abgekürzt 
als  d^B10,15(t)  geschrieben  werden. 


8.1.4.1    Resultate  bei  einer  Simulationsdauer  von  einem  Tag  (16  Umläufe) 

Wird  der  Simulationszeitraum  auf  einen  Tag  begrenzt,  so  ergeben  sich  die  in  Abbil- 
dung 8.3  dargestellten  Abstandsdifferenzen.  Hierbei  wurde  für  jedes  der  verwendeten 
Integrationsverfahren  zunächst  eine  genauere  Lösung  errechnet,  bei  der  32  signifikante 
Nachkommastellen  berücksichtigt  wurden.  Im  nächsten  Schritt  wurde  dann  eine  unge- 
nauere Lösung  mit  16  signifikanten  Nachkommastellen  Genauigkeit  zur  Berechnung 
verwendet.  Somit  liegen  nach  den  ersten  beiden  Schritten  die  Abstände  d^^it)  und 

d^6(t)  vor.  Als  Integrationsverfahren  kamen  SG,  BS,  RK10  und  RK4  zum  Einsatz. 


le-10  ,[ 


[SG]  Shampine- 
Gordon 

[BS]  Burlisch-Stoer 
[RK10]  Runge-Kutta 
10.  Ordnung 

[RK4]  Runge-Kutta 
4. Ordnung 


Abbildung  8.3:  Abstandsdifferenzen  verschiedener  Lösungen  über  einen  Simulations- 
zeitraum von  einem  Tag  (16  Umläufe) 

Nach  der  Simulation  stehen  Datensätze,  aus  denen  Abstandsdifferenzen  gebildet 
werden  können,  zur  Verfügung: 


dA,B  (*) 

d 

dA,B  (*) 

d 

,ÄX10,64/,x 
lA,B  \l) 

d 

dA,B  (*) 

d 

SG,1&,.\ 
A,B  \l) 

A,B  \l) 

RK 10, 16 /.\ 
A,B  \l) 

RK4,16/.\ 
A,B  \l) 


SG,64 


Die  Abstandsdifferenzen  aus  Abb.  8.3  wurden  mit  der  hochgenauen  Lösung  dA  ß 
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verglichen.  Dadurch  ergeben  sich  die  Abstandsdifferenzen: 

jSG,64,SG,16/.\ 
dA,B  (*) 

dA,B  (*) 

Bei  genauer  Betrachtung  der  Abstandsdifferenzen  fällt  auf,  dass  das  RK4- Verfahren 
trotz  höherer  dezimaler  Genauigkeit,  verglichen  mit  den  anderen  Verfahren,  größe- 
re Fehler  aufweist.  Der  Grund  hierfür  liegt  in  der  vergleichsweise  geringen  Ordnung 
des  Verfahrens.  Somit  kann  das  RK10- Verfahren,  aufgrund  seiner  größeren  Ordnung, 
genauere  Ergebnisse  erzielen.  Weiterhin  fällt  auf,  dass  die  Verfahren  mit  adaptiver 
Schrittweitensteuerung  stärkeren  Schwankungen  unterliegen.  Im  Allgemeinen  erzie- 
len die  Verfahren  mit  adaptiver  Schritt  Weitensteuerung  ein  besseres  Fehlerverhalten, 
was  hier  ebenfalls  abzulesen  ist. 


8.1.4.2    Resultate  bei  einer  Simulationsdauer  von  sieben  Tagen  (122  Umläufe) 

In  diesem  Abschnitt  wird  der  Integrationszeitraum  auf  sieben  Tage  erweitert,  um  den 
Verlauf  der  Abstandsdifferenzen  über  einen  längeren  Zeitraum  zu  beurteilen.  Die  re- 
sultierenden Abstandsdifferenzen  sind  in  Abb.  8.4  dargestellt.  Hier  zeigt  sich  bei  den 


500DO  100000  150000  200000          250000  300000  350000  400000          450000  50000C 

t[s] 


Abbildung  8.4:  Abstandsdifferenzen  verschiedener  Lösungen  in  einem  Simulations- 
zeitraum von  sieben  Tagen  (122  Umläufe) 


Verfahren  mit  fester  Ordnung  ohne  adaptive  Schrittweitensteuerung  ein  ähnliches  Ver- 
halten wie  im  vorausgegangen  untersuchten  Zeitabschnitt.  Die  Runge-Kutta- Verfahren 
können  aufgrund  ihrer  festgelegten  Ordnung,  auch  bei  Vergrößerung  der  signifikanten 
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Nachkommastellen,  kein  genaueres  Ergebnis  erzielen.  Wird  eine  Integration  mit  dem 
RK4- Verfahren  unter  Verwendung  herkömmlicher  Zahlenlänge  durchgeführt,  so  liegt 
der  absolute  Fehler  der  Abstandsdifferenz  nach  sieben  Tagen  bei  mehr  als  einem  Mil- 
limeter. Auch  die  Verfahren  mit  adaptiver  Schrittweitensteuerung  (SG  und  BS)  sind 
bei  diesem  Simulationszeitraum  deutlich  schlechter  als  1  Mikrometer,  wobei  das  BS- 
Verfahren  noch  den  kleinsten  absoluten  Fehler  aufweist. 

8.1.5  Fazit 

Im  Hinblick  auf  geplante  GRACE-Nachfolgemissionen4,  deren  Genauigkeiten  auf- 
grund technischer  Verbesserungen  und  einem  zusätzlich  an  Bord  befindlichen  Laser- 
entfernungsmesssystem5  im  Nanometer-Bereich  liegen  sollen,  müssen  die  numeri- 
schen Methoden  weiter  verbessert  werden. 

8.2    Berechnung  einer  Ephemeride  der  Mondbewegung 

8.2.1    Historie  des  Programmpakets  LUNAR 

Zur  Auswertung  und  Validierung  von  Laserentfernungsmessungen  zum  Mond  (LLR)  [llr]  Lunar  Laser 
wurde  an  der  Forschungseinrichtung  Satellitengeodäsie  der  Technischen  Universität  ^anging 
München  unter  Leitung  von  Prof.  Dr.  M.  Schneider  das  Programmpaket  LUNAR  ent- 
wickelt. Dieses  wurde  als  Teil  der  Dissertation  von  Herrn  B.  Reichhoff6  weiter  ver- 
bessert und  in  der  Programmiersprache  C++  neu  verfasst.  Insgesamt  besteht  dieses 
Programmpaket  aus  den  drei  Modulen:  VARIAT,  NORMAL  und  EPHEMER,  wobei 
letzteres  im  Rahmen  der  vorliegenden  Arbeit  verwendet  wurde.  Dessen  Funktionswei- 
se wird  im  Folgenden  kurz  beschrieben. 

•  EPHEMER 

Mit  diesem  Modul  kann  u.a.  der  Abstand  zwischen  Erde  und  Mond  simuliert 
werden.  Der  theoretische  Hintergrund  des  hierbei  implementierten  Modells  ist 
in  [Gleixner86],  [Bauer89],  [Müller91]  und  [Reichhoff99]  nachzulesen.  Auf- 
grund der  gravitativen  Wechselwirkung  zwischen  Erde,  Mond  und  der  Sonne 
mit  den  restlichen  Planeten  im  Sonnensystem  müssen  deren  Bewegungen  bei 
jedem  Berechnungsschritt  berücksichtigt  werden. 

In  Abb.  8.5  ist  die  Erde  -  Mond  -  Distanz-Berechnung  schematisch  illustriert.  Dabei  ist 
Rm  der  geozentrische  Ortsvektor  des  Mondes  bezüglich  der  Ekliptik.  Das  Programm- 
paket wurde  im  Rahmen  dieser  Arbeit  auf  ein  aktuelles  Linux-System7  portiert,  da  es 
aufgrund  der  sich  ständig  ändernden  Compilerversionen  und  den  damit  verbundenen 
Bibliotheksabhängigkeiten  nicht  mehr  übersetzbar  war.  Hierzu  war  es  außerdem  nötig, 
die  LiDIA-Bibliothek  der  Version  1.3  auf  das  aktuelle  Betriebssystem  zu  portieren. 

4  siehe  mehr  dazu  unter  [WatkinslO] 

5  siehe    hierzu    http://rses.anu.edu.au/geodynamics/GRACE_Follow_On/tech.php    Download  am 
25.11.2011 

6  siehe  mehr  dazu  in  der  Dissertation  von  B.  Reichhoff  [Reichhoff 99] 
7Ubuntu  Linux  10.10  (32-Bit),  gcc/g++-4.2 


8.2.2    Berechnung  einer  Ephemeride  durch  Integration  im  herkömmli- 
chen Modus 

In  diesem  Abschnitt  soll  EPHEMER  verwendet  werden,  um  über  einen  Zeitraum  von 
32  Jahren  eine  Ephemeride  des  Mondes  zu  berechnen.  Dabei  werden  alle  relevan- 
ten gravitativen  Einflussgrößen  mit  Post-Newtonscher  Näherung  im  Sonnensystem 
[abm]  Adams  berücksichtigt.  Als  Integrationsverfahren  wird  das  ABM-Verfahren  verwendet.  Ins- 
Bashforth  Mouiton  gesamt  werden  zwei  verschiedene  Lösungen  berechnet.  Die  erste  Lösung  wird  mit 
Hilfe  des  standardmäßig  verfügbaren  long  double -Datentyps  bestimmt,  was  folglich 
eine  absolute  Fehlertoleranz  von  1.0e-18  fordert.  Die  zweite  Lösung  wird  mit  Hilfe 
des  big/foat-Datentyps  der  LiDIA-Bibliothek  errechnet.  Hierbei  wird  die  Anzahl  si- 
gnifikanter Nachkommastellen  auf  80  und  die  geforderte  absolute  Fehlertoleranz  auf 
1.0e-38  festgelegt. 

Das  Ergebnis  des  Vergleichs  der  beiden  Lösungen  ist  in  Abbildung  8.6  dargestellt. 
In  den  ersten  drei  Graphen  ist  der  absolute  Fehler  der  Koordinatenunterschiede  auf- 
getragen. Dabei  fällt  auf,  dass  der  größte  Fehlerbeitrag  in  der  x  und  y  -  Koordinate 
liegt  und  sich  die  Fehlerentwicklung  der  drei  Koordinatenachsen,  trotz  unterschiedli- 
cher Größenordnung  in  der  z-Koordinate,  gleich  verhält.  Dies  lässt  auf  einen  Fehler  in 
alongtrack -Richtung  schließen8. 

Außerdem  ist  im  vierten  Plot  (Abb.  8.6,  unten)  der  absolute  Fehler  für  den  Erde-Mond- 
Abstand  aufgetragen.  Dort  fällt  auf,  dass  sich  nach  ca.  14  und  24  Jahren  der  absolute 
Fehler  auf  etwa  demselben  Niveau  (0,25  Meter)  befindet,  daraufhin  absinkt  und  an- 
schließend steil  auf  0.5  Meter  ansteigt.  Dies  bedeutet:  Wird  die  Simulation  mit  her- 
kömmlicher Genauigkeit  long  double  durchgeführt,  dann  besitzt  das  Ergebnis  eine 
Ungenauigkeit  von  0.55  Meter9.  Soll  über  diesen  Zeitraum  hinweg  integriert  werden, 
so  ist  die  Berechnung  mit  mehrfacher  Genauigkeit  durchzuführen. 


Siehe  dazu  die  Phasenverschiebung  der  x  und  y  -  Komponente  in  Abb.  F.  13  auf  Seite  225 
'siehe  dazu  auch  [EttllO] 
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Abbildung  8.6:  Vergleich  zweier  Lösungen  des  Erde-Mond  Abstands 


8.2.3    Erweiterung  von  EPHEMER 

Bei  der  Verarbeitung  der  Messdaten  muss  die  Bewegung  des  in  das  Sonnensystem  ein- 
gebettete Erde-Mond-Systems  in  nachnewtonscher  Näherung  gelöst  werden.  Die  itera- 
tive Bestimmung  von  Modellparametern  erfolgt  nach  dem  Verfahren  der  differentiellen 
Korrektur  von  apriori-Werten.  Dabei  fallen  bei  jedem  Schritt  eine  Ephemeridenrech- 
nung  des  gesamten  Sonnensystems,  eine  Berechnung  der  partiellen  Ableitungen  der 
testbaren  Funktionale  nach  den  Modellparametern  sowie  eine  Ausgleichsrechnung  der 
Beobachtungsgleichungen  an.  Die  Iteration  konvergiert  nur,  wenn  die  partiellen  Ab- 
leitungen, die  von  der  Genauigkeit  der  Ephemeridenrechnung  abhängen,  hinreichend 
genau  gerechnet  werden.  Hierzu  wird  im  Folgenden  das  Programm  EPHEMPER  er- 
weitert, um  zu  überprüfen,  welche  Genauigkeit  (exakte  Anfangsbedingungen  voraus- 
gesetzt) bei  Verwendung  des  double-Datentyps  erreichbar  ist. 

Die  hochgenaue  Berechnung  einer  Ephemeride  über  einen  längeren  Zeitraum  von  bei- 


spielsweise 30  Jahren  ist  auch  bei  heutigen  Rechnersystemen  noch  sehr  zeitauf- 
wendig. Beispielsweise  benötigt  die  Berechnung  einer  Ephemeride  mit  dem  ABM- 
Integrator  (Absolute  Fehlertoleranz  bei  1.0e-22)  unter  Verwendung  des  bigfloat-Daten- 
typs  bei  eingestellten  50  signifikanten  Nachkommastellen  auf  TP  1  etwa  12  Stunden. 
Die  neu  hinzugefügte  Funktionalität  von  EPHEMER  wird  als  Zweischritt-Modus  be- 
zeichnet. Die  Arbeitsweise  ist  außerdem  in  Abb.  8.7  illustriert. 

Im  ersten  Arbeitsschritt  wird  eine  Ephemeride  mit  hoher  Anzahl  signifikanter  Nach- 


stand November  201 1 

1 1  siehe  mehr  dazu  im  Abschnitt  A.  1 . 


[ABM]  Adams 
Bashforth  Moulton 

[TP1]  Testplattform  1 
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kommastellen  berechnet.  Hier  wird  analog  zum  klassischen  Betriebsmodus  der  gesam- 
te Zeitraum  integriert,  wobei  in  Abständen  von  einem  Jahr  Integrationszeit  die  jewei- 
ligen Positionsvektoren  der  Planeten  im  Sonnensystem  in  einer  entsprechenden  Datei 
abgelegt  werden. 


Schritt  1 


Zwischengespeicherte 
genaue  Anfangswerte 


Schritt  2 


Hochgenaue  Berechnung  mit  hoher  Anzahl  signifikanter  Nachkommastellen 

0  1  2  n-2  n-1 


-  I [Jahre] 


t\ Jahre] 


0  12  -  n-2 

Verminderte  Anzahl  signifikanter  Nachkommastellen 


n-1 


Abbildung  8.7:  Funktionsweise  der  EPHEMER  Erweiterung 

Im  zweiten  Schritt  können  die  zwischengespeicherten  Positionsvektoren  aus  dem 
ersten  Schritt  verwendet  werden,  um  bei  Rechnung  mit  herkömmlicher  Genauigkeit 
(long  doubie-Datentyp)  nach  jeweils  einem  Jahr  Integrationszeit  mit  genaueren  An- 
fangswerten zu  beginnen.  Dadurch  wird  erstens  kostbare  Rechenzeit  eingespart  und 
zweitens  ein  genaueres  Ergebnis  erzielt  als  mit  herkömmlicher  Genauigkeit.  In  Abb. 


Abbildung  8.8:  Qualität  der  Lösung  bei  der  Berechnung  im  Zweischritt-Modus 
(Jahresschritte) 


8.8  ist  das  Ergebnis  aus  dem  Vergleich  der  hochgenauen  Lösung  einer  Ephemeride  mit 
dem  Ergebnis  aus  dem  Zweischrittmodus  dargestellt.  Hierbei  kam  im  zweiten  Schritt 
der  long  doubie-Datentyp  und  der  ABM-Integrator  mit  einer  geforderten  absoluten 
Fehlertoleranz  von  1.0e-19  zum  Einsatz.  Die  hierfür  benötigten  Ergebnisse  wurden 
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im  ersten  Schritt,  bei  sonst  identischer  Konfiguration,  mit  dem  bigßoat-Datentyp  und 
einer  geforderten  absoluten  Fehlertoleranz  von  1  .Oe-22  erstellt.  Im  gesamten  Integra- 
tionszeitraum von  32  Jahren  liegt  die  erzielte  Genauigkeit  bei  ca.  14  cm.  Auffällig 
sind  dennoch  die  Anstiege  bei  12,  15,  20  und  30  Jahren.  Dieser  erste  Versuch  zeigt, 
dass  die  hierdurch  erzielte  Genauigkeit  noch  nicht  ausreicht,  um  mit  den  derzeit  er- 
reichbaren Genauigkeiten  der  Erde-Mond  Messungen  von  ca.  1  cm  schritthalten  zu 
können.  Aus  diesem  Grund  wird  eine  weitere  Modifikation  vorgenommen.  Anstatt  in 
Abständen  von  einem  Jahr  hochgenaue  Positionsvektoren  zu  laden,  wird  die  Integrati- 
on mit  hochgenauen  Anfangswerten  in  Monatsabständen  verwendet.  Der  Vergleich  der 
hochgenauen  Lösung  einer  Ephemeride  mit  dem  Ergebnis  aus  dem  Zweischrittmodus 
(Monatsabständen)  ist  in  Abb.  8.9  dargestellt. 


0  5  10  15  20  25  30  35 

t  []ohre] 

Abbildung  8.9:  Qualität  der  Lösung  bei  der  Berechnung  im  Zweischritt-Modus 
(Monatsschritte) 

Daraus  wird  ersichtlich,  dass  im  gesamten  Zeitraum  der  Integration  die  erzielte  Ge- 
nauigkeit unter  0.02  mm  liegt.  Somit  kann  diese  Variante  der  Ephemeridenberechnung 
als  guter  Kompromiss  zwischen  erzielter  Genauigkeit  und  benötigtem  Rechenaufwand 
betrachtet  werden.  Wie  diese  Beispiele  gezeigt  haben,  ist  jedoch  darauf  zu  achten,  in 
welchen  zeitlichen  Abständen  die  Zwischenschritte  verwendet  werden. 


8.2.4    Einfluss  des  impliziten  Rundungsfehlers  auf  die  Berechnung  des 
Erde-Mond  Abstands 

In  einem  weiteren  Experiment  wurde  das  EPHEMER-Programmpaket  verwendet,  um 
den  Einfluss  impliziten  Rundens  auf  die  Berechnung  des  Erde-Mond  Abstands  zu  un- 
tersuchen. Eine  Zahl  wird  implizit  gerundet,  falls  ihre  tatsächliche  Darstellung  nicht 
auf  die  Mantissenbits  der  Gleitkommazahlendarstellung  abgebildet  werden  kann.  Die- 
se spezielle  Form  der  Rundung  tritt  ausschließlich  beim  Basis  Wechsel  zwischen  Dezi- 
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mal  in  Binärsystem  auf.  Ein  Beispiel  hierfür  wurde  bereits  in  Abschnitt  3. 1.3  auf  Seite 
69  gegeben. 

Wie  in  den  vorangegangen  Experimenten  wird  die  jeweilige  Berechnung  des  Erde- 
Mond  Abstands  auf  zwei  unterschiedliche  Arten  durchgeführt.  Bei  der  ersten  Variante 
der  Berechnung  werden  alle  benötigten  Anfangswerte,  Koeffizienten  und  Konstanten 
mit  Hilfe  von  ASCII-Zeichenketten  initialisiert.  Damit  ist  es  möglich,  das  implizite 
Runden  im  Zusammenspiel  mit  dem  big/Ioat-Datentyp  und  einer  entsprechenden  An- 
zahl signifikanter  Nachkommastellen  zu  verhindern.  Bei  der  zweiten  Variante  wird 
implizites  Runden  explizit  erlaubt  und  es  werden  alle  notwendigen  Anfangswerte  in 
üblicher  Weise  initialisiert.  Außerdem  wurde  in  allen  durchgeführten  Berechnungen 
der  ABM-Integrator  mit  einer  absoluten  Fehlertoleranz  von  1.0e-22  eingesetzt.  Als 
Multiprecision-Datentyp  wurde  der  big/Ioat-Datentyp  der  LiDIA-Bibliothek  verwen- 
det und  auf  80  signifikante  Nachkommastellen  eingestellt. 


Epsilon  v-Komponente 
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Abbildung  8.10:  Einfluss  des  impliziten  Rundungsfehlers  auf  die  Berechnung  des 
Erde-Mond  Abstands 


In  Abb.  8.10  sind  die  Ergebnisse  des  Vergleichs  der  beiden  Berechnungen  illu- 
striert. Die  ersten  drei  Graphen  stellen  den  absoluten  Fehler  in  den  kartesischen  Ko- 
ordinaten dar.  Hier  ist  analog  zur  vorausgegangenen  Berechnung  (siehe  Seite  8.6)  der 
Fehlerbeitrag  der  x  und  y  -  Komponente  größer  als  die  der  z-Komponente.  In  der  vier- 
ten Graphik  (Abb.  8.10)  ist  der  absolute  Fehler  des  geozentrischen  Abstands  aufgetra- 
gen. Dieser  liegt  maximal  bei  1.4e-5  Meter  (0.014  mm)  und  ist  somit  kein  potentieller 
Einflussfaktor  für  verfälschte  Ergebnisse  bei  Berechnungen  dieser  Art.  Außerdem  soll 
noch  bemerkt  werden,  dass  der  absolute  Fehler  aus  der  Berechnung  der  Monatslösung 
(siehe  Abb.  8.9)  die  selbe  Größenordnung  aufweist. 


Kapitel  9 

Ausblick 


In  den  vorausgegangen  Kapiteln  wurde  das  Konzept  einer  Toolbox  zur  numerischen 
Lösung  gewöhnlicher  Differentialgleichungen  vorgestellt.  Ihre  Einsatzbereitschaft  wur- 
de insbesondere  anhand  der  Abstandssimulation  der  beiden  GRACE-Satelliten  und 
anhand  der  Berechnung  der  Erde-Mond-Distanz  demonstriert.  Daraus  hat  sich  ge- 
zeigt, dass  bei  der  Rechnung  mit  16  signifikanten  Nachkommastellen  die  Ergebnis- 
se nicht  immer  den  geforderten  Genauigkeiten  genügen.  Dieser  Nachteil  kann  durch 
den  Einsatz  von  muitiprecision-Bibliotheken  beseitigt  werden.  Die  Toolbox  besteht 
sowohl  aus  Ein-  und  Mehrschrittverfahren  als  auch  aus  Potenzreihenintegrationsver- 
fahren,  welche  aufgrund  des  erarbeiteten  objektorientierten  Designs  mit  verschiede- 
nen muitiprecision-Bibliotheken  verwendet  werden  können.  Insbesondere  der  zusätz- 
liche Freiheitsgrad  der  frei  wählbaren  Anzahl  signifikanter  Nachkommastellen  bei  der 
numerischen  Integration  hat  sich  als  wertvolles  Hilfsmittel  erwiesen,  Ergebnisse  zu 
validieren  und  höhere  Genauigkeiten  zu  erreichen.  Außerdem  können  damit  bestehen- 
de Programmsysteme  hinsichtlich  ihrer  numerischen  Stabilität  überprüft  werden.  Der 
zeitliche  Mehraufwand  bei  der  Berechnung  mit  höherer  Anzahl  signifikanter  Nach- 
kommastellen kann  durch  die  vorgestellten  Methoden  zur  Laufzeitverbesserung  in  vie- 
len Fällen  abgeschwächt  werden. 

Im  Folgenden  sollen  weiterführende  Gedanken  zur  untersuchten  Thematik  angespro- 
chen werden,  die  in  zukünftigen  Arbeiten  zu  diesen  oder  verwandten  Themenstellun- 
gen angegangen  werden  könnten. 

9.1    Internationaler  Standard  für  numerische  Verfahren 

Es  gibt  unzählige  Veröffentlichungen,  in  denen  numerische  Integrationsverfahren  als 
Hilfsmittel  eingesetzt  wurden,  um  gewöhnliche  Differentialgleichungen  aller  Art  zu 
lösen.  Die  hierfür  verwendeten  Verfahren  entstammen  dabei  aus  unterschiedlichen 
Quellen,  wurden  mit  verschiedenen  Programmiersprachen  umgesetzt  und  oft  auf  nicht 
näher  spezifizierten  Computerplattformen  berechnet.  Folglich  besteht  die  Notwendig- 
keit, einen  internationalen  Standard  für  numerische  Verfahren,  ähnlich  dem  IEEE  Stan- 
dard für  Arithmetik  von  Gleitkommazahlen,  auszuarbeiten.  In  diesem  sollten  demnach 
die  Standard  verfahren  als  Pseudocode  definiert  sein.  Daraus  könnten  dann  für  die  je- 
weiligen Programmiersprachen  Bibliotheken  entwickelt  werden.  Damit  wären  die  Er- 
gebnisse, welche  auf  unterschiedlichen  Rechnersystemen  und  Programmiersprachen 
erstellt  wurden,  besser  vergleichbar. 


177 


178 


Kapitel  9:  Ausblick 


9.2    Schnelles  Rechnen 

Höhere  Rechengeschwindigkeiten  spielen  insbesondere  bei  der  Simulation  mit  ho- 
her Anzahl  signifikanter  Nachkommastellen  eine  entscheidende  Rolle.  Aus  diesem 
[GPU]       Graphics  Grund  erscheinen  die  Berechnungsmöglichkeiten  des  GPU-Computings,  basierend  auf 
Processing  Unit         ^  OpenACC-Schnittstelle,  zukunftsweisend.  Ferner  könnten  Programme  auf  FPGA- 
[fpga]  fieid  ßaustemen  abgebildet  werden  und  dadurch  einen  erheblichen  Geschwindigkeitszu- 

programmable      gate  °  ° 

array  ~     wachs  erfahren. 


9.3    Untersuchung  zu  multiprecision -Bibliotheken 

In  dieser  Arbeit  wurden  Untersuchungen  zur  Eignung  einiger  frei  verfügbarer  multi- 
precision -Bibliotheken  angestellt.  Diese  Vergleiche  könnten  auf  eine  größere  Menge 
Bibliotheken  und  Programmiersprachen  ausgeweitet  werden.  Dadurch  könnten  Infor- 
mationen zur  momentanen  Leistungsfähigkeit  heutiger  Bibliotheken  gesammelt  wer- 
den, die  u.U.  als  Entscheidungshilfe  für  spätere  Projektvorhaben  dienen  könnten. 
Ein  weiteres  Entwicklungsfeld  stellt  die  automatische  Validierung  errechneter  Ergeb- 
nisse unterschiedlicher  muJtiprecision-Bibliotheken  dar.  Hierzu  wäre  es  erforderlich, 
für  die  jeweiligen  Bibliotheken,  Testprogramme  zu  entwickeln,  welche  auf  verschie- 
denen Plattformen  mit  Hilfe  von  unit-Tests  die  korrekte  Arbeitsweise  der  Bibliothe- 
ken nachweisen.  Somit  könnten  versteckte  Ungenauigkeiten  schon  im  Vorfeld  detek- 
tiert  werden,  was  die  Vertrauenswürdigkeit  derartig  bestimmter  Ergebnisse  nachhaltig 
fördern  würde.  Mögliche  Ansatzpunkte  wären  die  Weiterentwicklung  des  Programms 
Arithmos1,  mit  dem  mathematische  Berechnungen  mit  Hilfe  hochgenauer  Rechnung 
validiert  werden  können. 

Eine  zusätzliche  Möglichkeit  könnte  die  Erweiterung  einer  Compilersuite  um  einen 
multiprecision  -Datentyp  sein.  Dessen  jeweilige  Genauigkeit  könnte  beispielsweise  beim 
Übersetzungsvorgang  angegeben  werden.  Dies  würde  die  Entwicklung  numerischer 
Berechnung  mit  C/C++  deutlich  vereinfachen. 


9.4    Erweiterung  der  Integratoren 

Im  Rahmen  dieser  Arbeit  wurden  eine  ganze  Reihe  verschiedener  Integrationsverfah- 
ren implementiert.  Es  gibt  dennoch  einige  Verfahren,  die  noch  nicht  im  Repertoire 
enthalten  sind.  Dazu  gehören  beispielsweise  das  Runge-Kutta-Shanks-Verfahren2  oder 
der  Verlet-Integrator.  Darüber  hinaus  fehlen  noch  Verfahren,  vom  Gauß-Jackson  Ver- 
fahren abgesehen,  zur  Lösung  von  Differentialgleichungen  2. Ordnung.  Außerdem  wä- 
re es  überaus  hilfreich,  eine  adaptive  Schrittweitensteuerung  für  den  Potenzreiheninte- 
grator zu  implementieren. 


'siehe  mehr  dazu  auf  der  Webseite  des  Projekts:  http://cant.ua.ac.be/old/arithmos/,  Download  am 
26.11.2011 

2  siehe  mehr  dazu  unter  [Schneider99],  Seite  1047 
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9.5  Erweiterung  der  Toolbox 

Die  Toolbox  könnte  in  einer  weiteren  Ausbaustufe  um  Verfahren  zur  Lösung  von 
Randwertproblemen  aufgestockt  werden.  Damit  könnte  es,  aufgrund  der  Möglichkeit 
mit  höherer  Anzahl  signifikanter  Nachkommastellen  zu  rechnen,  ein  nützliches  Werk- 
zeug bei  Bahn  -  und  Parameterbestimmung  von  Ephemeriden  werden. 
Zusätzlich  wäre  es  hilfreich,  das  Programm  EPHEMER  und  die  darin  enthaltenen  Be- 
wegungsgleichungen auf  C++-Templates  umzustellen.  Ferner  sollten  die  verfügbaren 
Bewegungsgleichungen  um  zusätzliche  Kraftanteile,  wie  beispielsweise  den  Einfluss 
des  Strahlungsdrucks  der  Sonne,  erweitert  werden. 

9.6  Graphische  Benutzeroberfläche 

Schließlich  wäre  es  lohnenswert,  das  entwickelte  Programmsystem  mit  einer  graphi- 
schen Benutzeroberfläche  auszustatten.  Dadurch  würde  die  Bedienung  erheblich  er- 
leichtert und  wäre  folglich  einem  breiteren  Benutzerkreis  zugänglich.  Als  potentielle 
Bibliotheken  zur  Realisierung  einer  graphischen  Benutzeroberfläche  werden  wxWid- 
gets3  oder  Qt4  angesehen. 


3  siehe  mehr  dazu  auf  der  Webseite  des  Projekts:  http://www.wxwidgets.org,  Download  am  26.1 1.201 1 
4siehe  mehr  dazu  auf  der  Webseite  des  Projekts:  http://qt.nokia.com/,  Download  am  26.1 1.201 1 
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Anhang 


A.l    Beschreibung  der  Testplattformen 

Nachfolgend  sind  die  Leistungsmerkmale  der  eingesetzten  Testplattformen  aufgelistet. 
Durch  Angabe  dieser  Merkmale  erhalten  die  Geschwindigkeitsmessungen  ihre  Aussa- 
gekraft. Ferner  ist  es  dadurch  jederzeit  möglich,  die  Ergebnisse  einer  nachträglichen 
Verifikation  zu  unterziehen. 


A.1.1    Testplattform  1 


Betriebssystem 

Ubuntu  Linux  7.10 

Kernelversion 

2.6.22-14-generic  x86-64 

Prozessor 

Intel  Core  2  Duo  T7300  [Family  6  Model  15  Stepping  10] 

Arbeitsspeicher 

2.0  GB 

Compilerversion 

gcc-4.2.1  /g++-4.2.1 

Compilerfiags 

-m64 

Tabelle  A.  1 :  Eckdaten  der  Testplattform  1 


A.1.2    Testplattform  2 

Diese  Testplattform  besitzt  eine  CPU  mit  HT-Technologie.  Die  HT- Technologie  stellt  [HT]  Hyperthreading 
eine  Implementierung  von  hardwareseitigem  Multithreading  dar.  Mit  anderen  Wor- 
ten, es  wird  ein  zweiter  Rechenkern  simuliert.  Dadurch  kann  diese  Plattform  auch  als 
Testumgebung  zur  Parallelverarbeitung  eingesetzt  werden.  Dieses  Feature  wurde  bei 
allen  Berechnungen  eingeschaltet. 


Betriebssystem 

Debian  Edge 

Kernelversion 

2.6.17.1 

Prozessor 

Pentium  4  3.0GHz  (HT) 

Arbeitsspeicher 

1.0  GB 

Compilerversion 

gcc-4.2.1  /g++-4.2.1 

Compilerfiags 

-m32 

Tabelle  A.2:  Eckdaten  der  Testplattform  2 
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Anhang  B 


Formale  Darstellung  der  Rücksubstitution 


Eine  Differentialgleichung  kann  mit  Hilfe  eine  Taylorreihenentwicklung  gelöst  wer- 
den. Dazu  ist  es  erforderlich,  analytische  Ableitungen  höherer  Ordnung  zu  bestimmen. 
Betrachtet  man  die  analytisch  bestimmten  Ableitungsterme  genauer,  so  stellt  man  fest, 
dass  diese  nicht  nur  von  Ort  (^f )  und  Geschwindigkeit  (4rf ),  sondern  auch  von  den 
Ableitungstermen  niederer  Ordnung  implizit  abhängig  sind.  Durch  diese  Abhängig- 
keit müssen  die  vorangegangenen  Ableitungen  bekannt  sein,  um  die  nächsthöhere  zu 
bilden.  Folglich  ist,  zumindest  in  dieser  Darstellung,  die  Berechnung  einzelner  Ablei- 
tungsterme nicht  zur  parallelen  Abarbeitung  geeignet.  Im  Folgenden  soll  aufgezeigt 
werden,  wie  durch  sukzessives  Rückwärtseinsetzen  (Rücksubstitution)  Ableitungster- 
me höherer  Ordnung  berechnet  werden  können,  die  zur  Parallelverarbeitung  geeignet 
sind.  Ferner  wird  ein  Bildungsgesetz  aufgezeigt,  welches  die  Berechnung  eines  be- 
stimmten Reihenkoeffizienten  i  ermöglicht,  ohne  die  vorangegangenen  Ableitungster- 
me niedrigerer  Ordnung  zu  kennen. 


B.l    Vollständiges  Differential 

Wenn  u(x,  y)  eine  differenzierbare  Funktion  ist  und  von  den  unabhängigen  Variablen 
x  und  y  abhängig  ist,  so  wird  das  vollständige  Differential  (D^)  erster  Ordnung  durch 
partielle  Ableitungen  wie  folgt  ausgedrückt: 

D^:=du=^dx+^dy  (B.l.l) 
ox  oy 

Höhere  partielle  Ableitungen  der  Ordnung  n  werden  rekursiv  definiert  durch: 

D(n)  =  ol>  ^  +  au  dy  m2) 

ox  oy 

Voraussetzung  hierzu  ist: 

Werden  höhere  partielle  Ableitungen  gebildet,  so  kann  erst  nach  einer  unabhängigen 
Variablen  abgleitet  werden  und  schließlich  nach  einer  anderen.  Diese  Form  wird  als 
gemischt  partielle  Ableitung  bezeichnet.  Eine  partielle  Ableitung  nach  x  und  dann 
nach  y  wird  beschrieben  durch: 

d2u  d2u 
dxdy  dydx 
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Anhang  B:  Formale  Darstellung  der  Rücksubstitution 


Der  Wert  einer  gemischten  Ableitung  ist  für  gegebene  Werte  von  x  und  y  unabhän- 
gig von  der  Reihenfolge  der  Ableitungsbildung,  wenn  die  gemischte  Ableitung  in  den 
betrachteten  Punkt  stetig  ist1. 

B.l.l  Rücksubstitution 

Zur  Lösung  einer  Bewegungsgleichung  (Differentialgleichung)  2.  Ordnung  werden  fol- 
gende Anfangswerte  benötigt: 

•  Ort  u 

•  Geschwindigkeit  ü 

Außerdem  wird  die  Differentialgleichung  ü(u,  u)  in  den  weiteren  Schritten  benötigt. 
Sind  diese  Angaben  vorhanden,  so  können  zunächst  höhere  Ableitungen  gebildet  wer- 
den: 

d}ü  d}ü{u,u) 


dt1  dt1 
d2ü  d2ü{u,u) 


dt2  dt2 
dnü      dnü(u,  u) 


dtn  dtn 

Aus  dieser  Darstellung  wird  die  Abhängigkeit  zwischen  den  unterschiedlichen  Ord- 
nungen ersichtlich,  d.h.  um  die  Ableitung  der  Ordnung  n  zu  bilden,  werden  die  voran- 
gegangen Ableitungen  der  Ordnungen  <  n  benötigt.  Außerdem  erhält  man  Ableitun- 
gen, die  implizit  von  niedrigeren  Ordnungen  abhängen. 

Mit  Hilfe  des  vollständigen  Differentials  lässt  sich  folgende  Darstellung  gewinnen: 

d1!!      dü  .     dü .. 

dt1      du  dü 

d2ü  _  d2  ,d1ü  .      d2  .. 

~d¥  ~  du2{W)u  +  dl?u 

dnü  _  dn    dn~lü         dn  dn^ü 
~dF  ~  dvP^  dt™-1  'U  +  düP^  dt11-1  'U 

Soll  beispielsweise  der  5.  Ableitungsterm  berechnet  werden,  dann  ergeben  sich  fol- 
gende Zwischenergebnisse: 

d5ü      d   d4ü  .      d  ,dAü 

~d¥  =  d^[H^)u+dii[^)u 

Wird  die  partielle  Ableitung  der  4. Ordnung  eingesetzt: 

d5ü      d  .  d  ,d?u\        d  ,d3ü\  ,        d  ,  d  .d3ü         d  .d3ü 

W  =  Tu[Tu{^)u  +  dü{^)u]u  +  dü[Tu{^)u  +  dü{W)u]u 


'siehe  dazu  [Bronstein08] 


B.l  Vollständiges  Differential 
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Nach  Einsetzen  der  3. Ableitung: 

d5ü      d  r  d    d  ,d2ü.        d  ,d2ü.  d    d  ,d?ü.        d  ,d2ü 

dfi  =  Tu[Tu{d-u{^)u+  dü{W)u)u  +  Tü{Tu{^)u  +  dü^)u)u]u 

d  r  d    d  ,d2ü\       d  ,d2ü.  d    d  .d2ü.        d  ,d2u\  , 

+  ÄW^)n  +  dü{W)u)u+  dü^W)u  +  dü{dfi)u)u]u 

Nach  Einsetzen  der  2.Ableitung: 

d5ü      d    d    d     d   dlü         d  ,dlü  d     d  ,dlü         d  ,dlü.  , 

W  =Ä(Ä(dF)u  +  dü{W)u]u  +  dü{W)u]u)u 

d    d    d  /d1ü.        d  /d1ü.  ,        d    d  .dlü         d  ,d1ü.  ,  . 

+  Tü{tJTu{  -W)u  +  Tü{^)u]u  +  T^Tu{^)u  +  dü{W)u]u)u]u 

d    d    d    d  ,dlü.        d  ,dlü  d    d  ,dlü         d  ,dlü 

dü{W)u]u  +  düld^{W)u  +  dü{W)u]u)u 

d    d    d  .d}ü\       d  .dlü\  ,        d    d  /d1ü         d  ,d1ü.  ,  . 

+  ^(Ä(dF)n  +  dü{W)u]u+düld^{W)u  +  dü{W)u]u)u]u 

Nach  Einsetzen  der  1. Ableitung: 

d5ü  _  d  .  d  ,  d    d  .dü  .  ^  dü ...  .  ^  d  .dü  .  ^  dü ........  ^  d  -  d  .dü  .  ^  dü 

dt5     du  du  du  du  du       du  du  du       dü  dü  du  du  du 

d   dü  .     dü ...........      d    d    d   dü  .        dü  d   dü  .     dü . 

dü  du       dü  du  du  du  du       d  dotu         dü  du  dü 

d    d   dü  .     dü ...  .      d   dü  .     3ü ..  .   ..  . 

dü  du  du       dü  du  du  dü 

^  d    d    d    d   dü  .  ^  dü  .     ^  d   dü  .  ^  dü  ..  ..  .  ^  d    d   dü  .  ^  dü 

dü  du  du  du  du       dü         du  du       dü  dü  du  du  du 

d   dü  .     dü ...........      d    d    d   dü  .     dü  d   dü  .     dü . 

dü  du       dü  du  du  du  du       dü         dü  du  dü 

d    d   dü       dü ...        d   dü  dü 

+  dü  ^d-u{Tuu  +  Tüu)u  +  Tü{Tuu+  düu)u]u)u]u 

Hier  kann  nicht  weiter  rücksubstituiert  werden,  da  die  2.  Zeitableitung  durch  die 
Differentialgleichung  ausgedrückt  wird.  Aus  dieser  Darstellung  lassen  sich  einige  In- 
formationen gewinnen: 

•  Die  Anzahl  der  Terme  einer  rücksubstituierten  Darstellung  nimmt  um  2°rdnun9+1 
zu,  d.h.  um  die  jeweiligen  Ordnungen  zu  bestimmen,  wird  die  folgende  Anzahl 
Terme  benötigt: 

-  Ordnung  1  :  21  =  2  Terme 

-  Ordnung  2  :  22  =  4  Terme 

-  Ordnung  3  :  23  =  8  Terme 

-  Ordnung  n  :  2n  Terme 

•  Um  die  vollständige  Ableitung  in  Form  einer  bestimmten  rücksubstituierten  Ab- 
leitung einer  gewissen  Ordnung  zu  bestimmen,  muss  die  Reihenfolge  der  parti- 
ellen Ableitungen  für  jeden  der  20rdnung+1  Terme  bekannt  sein. 
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Anhang  B:  Formale  Darstellung  der  Rücksubstitution 


Um  einen  Reihenterm  einer  bestimmten  Ordnung  zu  berechnen,  müssen  alle  vor- 
herigen Ableitungsterme  ermittelt  werden.  Werden  rücksubstituierte  Reihenkoeffizi- 
enten gebildet,  so  geschieht  dies  durch  aufeinander  folgendes  partielles  Differenzieren 
des  vorangegangen  Terms.  Die  Entwicklung  ist  in  Abbildung  B.l  dargestellt. 


d}ü 
dt1 

d2ü 
dt2 

d3ü 


wobei 


fo  h 
/o/o  /o/i  /i/o 

s       \       s       \      s       \  s 


Tabelle  B.l:  Entwicklung  höherer,  rücksubstituierter  Ableitungsterme 


,      dü . 

h  =  Tuu 


,      dü .. 

h  =  Tüu 


gesetzt  wurde.  Außerdem  werden  gemischt  partielle  Ableitungen  wie  folgt  abgekürzt 
geschrieben: 


hh  -  -£-4 


Aus  Tabelle  B.l  kann  das  Bildungsgesetz  zu  Bestimmung  eines  bestimmten  Rei- 

dH 
di-' 


henkoeffizienten  abgelesen  werden.  Beispielsweise  sind  zur  Berechnung  von  ^  fol 


gende  partielle  Ableitungen  zu  bilden: 


^3  —  /o/o/o  +  /o/o/i  +  /o/i/o  +  /o/i/i  +  /i/o/o  +  /1/0/1  +  /1/1/0  +  /l/l/l 

Betrachtet  man  die  Indices  genauer,  so  entspricht  dies  exakt  der  Binärkodierung,  wie 
sie  bei  der  digitalen  Verarbeitung  von  Information  verwendet  wird.  Grundlage  eines 
jeden  Binärcodes  ist  ein  so  genanntes  Binäres  System,  d.h.  ein  System,  in  dem  nur 
ausschließlich  zwei  Zustände  herrschen  (hier  0  oder  1).  Bei  der  Zahlendarstellung  im 
Dualsystem  werden  die  Ziffern  zi  wie  im  gewöhnlich  verwendeten  Dezimalsystem 
ohne  Trennzeichen  hintereinander  geschrieben,  ihr  Stellenwert  entspricht  allerdings 
der  zur  Stelle  passenden  Zweierpotenz  und  nicht  der  Zehnerpotenz.  Die  höchstwertige 
Stelle  mit  dem  Wert  zrn  wird  ganz  links  und  die  niederwertigen  Stellen  mit  den  Werten 
zm-i  biszo  in  absteigender  Reihenfolge  rechts  davon  geschrieben. 


wobei 


z  G  N,Zi  G  {0,1} 


B.l  Vollständiges  Differential 
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Die  dezimale  Darstellung  kann  durch  folgenden  Zusammenhang  bestimmt  werden: 

m 

Z  =  ^  zi  *  2* 

i=0 

In  Tabelle  B.2  ist  die  Binärcodierung  für  den  Fall  ^  dargestellt.  Hierbei  ist  zu  sehen, 
dass  die  Anzahl  der  zu  berechnenden  Terme  mit  jeder  hinzukommenden  Ordnung  um 
eine  Spalte  (im  Binärsystem)  steigt. 


Binär 

Dezimal 

Folge  aufeinanderfolgender  partiellen  Ableitungen 

000 

0 

/o/o/o 

001 

1 

/o/o/i 

010 

2 

/o/i/o 

011 

3 

/o/i/i 

100 

4 

/i/o/o 

101 

5 

/l/o/i 

110 

6 

/i/i/o 

111 

7 

/i/i/i 

Tabelle  B.2:  Folge  aufeinanderfolgender  partieller  Ableitungen  in  binärer  und  dezima- 
ler Darstellung 

Die  Berechnung  einzelner  Reihenkoeffizienten  kann  mit  Hilfe  symbolischer  Rech- 
nung bestimmt  werden.  Durch  die  vorher  gezeigte  Entwicklung  ist  die  Berechnung 
der  Reihenkoeffizienten  parallelisierbar,  d.h.  die  jeweils  zu  berechnenden  Koeffizien- 
ten können  unter  Ausnutzung  von  Mehrkernprozessoren  bestimmt  werden.  Dadurch 
können  in  kürzerer  Zeit  Terme  höherer  Ordnung  berechnet  werden.  Diese  wiederum 
sind  bereits  rücksubstituiert  und  können  ebenfalls  parallel  ausgewertet  werden,  was 
einen  Zuwachs  der  Abarbeitungsgeschwindigeit  auf  Mehrkernprozessoren  verspricht. 
Dies  soll  am  Beispiel  der  Differentialgleichung  des  Duffing-Oszillators  demonstriert 
werden.  Die  Differentialgleichung  des  ungedämpften  Duffing-Oszillators  ist  wie  folgt 
definiert: 


ü  =  —ui2ü  —  eü3 

wobei: 

•  ü  die  zweite  Ableitung  nach  der  Zeit  ist. 

•  ü  die  erste  Ableitung  nach  der  Zeit  ist. 

•  üj  und  s  konstante  Faktoren  sind. 

Das  folgende  Programm  berechnet  Reihenkoeffizienten  bis  zu       mit  Hilfe  von  Symbolic- 
C++  und  gibt  das  jeweilige  Ergebnis  in  die  Standardausgabe  aus.  Die  Ordnung  der  Ab- 
leitungsterme  kann  durch  Angabe  eines  Kommandozeilenparameters  angegeben  wer- 
den. 
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Anhang  B:  Formale  Darstellung  der  Rücksubstitution 


1 

#include   "  symbolicc ++.h" 

2 

int   main(int    iargc  ,    char  *argv[]) 

3 

{ 

4 

int   iN  =  10; 

5 

if(iargc   >=  1) 

6 

iN  =atoi ( argv [ 1 ] ) ; 

7 
8 

if(iN  <  0) 

{ 

9 

std::cerr  «  "negative   number  pro  vided  !  \  n "  ; 

10 

exit(-l)  ; 

11 

) 

12 

Symbolic  omega(  "omega" )  ,u("u")  ,  eps  ( "  eps  " )  ,  t  ( "  t 

"); 

13 

u=u[t]; 

14 

Symbolic  F; 

15 

F  =  -((omegaA(2) )*u)  -  ( eps * (u A ( 3 ) ) ) ; 

16 

Symbolic           dF  =  df  (F   ,  t)  ; 

17 

std::cout  «  dF  «  std  : :  endl ; 

18 

for( int    i  =  0;    i  <  iN ;    i ++) 

19 

{ 

20 

Symbolic  ddF  =  df  ( dF  ,  t )  [ (  df  (  df  (u  ,  t )  ,  t ) )  == 

F  ] ; 

21 

std::cout  «  ddF  «  std:: endl; 

22 

dF  =  ddF; 

23 

) 

24 

return  0; 

25 

} 

Listing  B.l:  Beispielprogramm  zum  Erzeugen  höherer  Ableitungen 


Folgend  sind  die  höheren  Ableitungen  bis  zur  5.  Ordnung  angegeben.  Mit  dem 
oben  gezeigten  Programm  können  prinzipiell  beliebig  hohe  Ableitungsterme  berechnet 
werden. 

3üsu2  —  üüj2 

Qu2  eu  +  üjau  +  Aeußv?  +  3e2u5 
6n3e  +  üuj4  +  24üajV  +  27üe  V 


Diese  sollen  im  Folgenden  auf  ihre  Richtigkeit  überprüft  werden,  indem  sie  mit  der 
numerisch  berechneten  Lösung  des  Potenzreihenintegrators  verglichen  werden.  Au- 
ßerdem soll  gezeigt  werden,  wie  ein  bestimmter  Ableitungsterm  berechnet  wird.  Das 
daraus  resultierende  Ergebnis  wird  ebenfalls  mit  dem  Potenzreihenintegrator  vergli- 
chen. 


d?ü 
~d¥ 
d*ü 
~d¥ 
d5ü 

~d¥ 

dPü 

~d¥ 


Anhang  C 

Höhere  Ableitungen  der  Keplerbahn 


Die  folgenden  Variablen  werden  als  gegeben  vorausgesetzt: 
fx(t)\ 

r=   y(t)   ;  r  =  V*2(*)  +  y2(*)  +  z2(*); 

W)/ 

dr  =  2z  (t)  (£z  (t))  +  2y  (t)  (£y  (t))  +  2x  (t)  (£x  (t))  = 
dt  2^2  (t)  +  y2  (t)  +  X2  (f)  r  ' 

/*  =  GMe; 
dabei  ist: 

•  r  der  Ortsvektor  im  Inertialsystem  und  r  die  geometrische  Distanz. 

•  r  der  Vektor  der  Geschwindigkeitskomponenten  und  f  die  Radialgeschwindig- 
keit. 

•  ß  die  Gravitationskonstante  G  multipliziert  mit  der  Masse  der  Erde  M®. 

•  t  die  Zeit. 

Hinweise  zur  Notation 

Der  Ausdruck  [ab]  entspricht  dem  Skalarprodukt  zweier  Vektoren,  d.h.  [ab]  :=  ao&o  +  •••  +  anb. 
Wobei  die  Vektoren  a  und  b  aus  n  +  1  Komponenten  bestehen. 

Diese  Notation  ist  insbesondere  zur  Kontrolle  der  Dimension  größerer  Ausdrücke  hilfreich. 


x(t)\ 
r=  y(t) 
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Anhang  C:  Höhere  Ableitungen  der  Keplerbahn 


=  r 


<i°F 
dfi 

~d¥ 

d?r  r 

dt2  ^  r3 

d3f  r  3F[FF] 

^3  =  ~ 

d4r  r3F([Ff]  +  [Ffl)  15F[Ff]2  6F[Ff]  1  - 
^4=^[  ,5  -—y-  +  -jT-^ 

d5f  _  ,3F([F0]  +  3[Ff])     45F[FF](FF+  [Ff])     9F([Ff]  +  [f]2)     105F[FF]3     45F[FF]2  9F[FF] 

^>5  y*7  y»5  ^>9  y*7  y»5 

SP=     3F([Fg]  +  4[Fg]  +  3g)     60F[Fr]([Fg]  +  [3fF])  |  12F([Fg]  +  [3Ff]) 

630F[Ff]2([FF]  +  [FF])     180F[FF]([FFj  +  [FF])     18f*([Ff]  +  [FF])     945F[FF]4  420F[FF]3 


y»5  y  1 1_  y9 


90F[FF]2     120  [Fr]     g     45F([Ff]  +  [Ff])2 


y7  yö  y*3  iyT 

£?  =     3F([Fg]  +  [5Fg]  +  [lOgg])     ff     75F[Fj([Fg]  +  4[Fjg]  +  3[rF]) 
dt7      M  r5  r3  r7 

|  15F([Fg]+4[fg]  +  3[Ff])  |  15[FF]g     150F([Ff]  +  [Ff])([Fg]  +  3jfg) 

y>5  y>5  y>7 

3OF([F0]  +  3[Ff])     1050F[Ff]2([Fg]  +  3[fF])     300F[FF]([  vecrg]  +  3[Ff]) 

y*5  y»9  y»7 

300  ([Ff]  +  [Ff])     150|f[Ff]2     1575F[Ff]([Ff]  +  [Ff])2     225F([Ff]  +  [ff])2 


y>7  y»9  y*7 


450F[FF]([FF]  +  [Ff])     9450F[FF]3([Ff]  +  [Ff])     3150F[FF]2([Ff]  +  [Ff])  1050F[Fff 


y7  y  1 1  y9  y9 


10395F[Ff]5  4725F[Ff]4 
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fr        3([Fg]  +  6[Fg]  +  15[fg]  +  10[gg])F  _  90[rg([rg]  +  5[fg]  +  10[fg])f 
150([fg]  +  3[rf])2)F     225([g  +  [gj)  ([rg]  +  4[fg]  +  3[FF])F 

y  7  rj^T 


1575[FFj2([F|J]  +  4[ff£]  +  3[Fr])F     1575([Fr]  +  [FF])3F 


+    r9    + 

6300[FF]([FF]  +  [FF])([F|f]  +  3[Frj)F     18900  [FF]3  ([Ff|f]  +  3[rf])F 

y  9  j^*  1  1 

42525[FF]2([FF]  +  [FF])2F     135135[FF]6F     155925[FF]4([FF]  +  [FF])F 
|  l8([r|f;]  +  5[Fg]  +  10[Fgf])F     450g([rg]+  4[Fjg]  +  3[Fg])F 
900([FF]  +  [FF])([F|£]  +  3[FFj)F     6300  [FF] 2  ([rg]  +  3[FF])F 

y»7  ^>9 

9450[FF]([FF]  +  [FF])2F     56700  [FF]3  ( [FF]  +  [FF]  )F  62370[FFj5F 

^9  y»  1 1  ^>13 

|  45([rg]  +  4[gg]  +  3jg)F     675([FF]  +  [gff 

_  900[FF]([Fg]  +  3[g)g     9450 [fr] 2 ([rg  +  [FF])F  14175[FF]4F 

y7  y9  ^-»11 

|  60qFg]+3[FFj)g     9Q0[r>i([r^  +  [Fr])g  |  2100[r?]3g£ 

iy\)  y7  ^>9 

+  45([FF]  +  [FF])g  _  225[FF]2g  +  18[FF]g  _  g 

y»5  y7  y5  y3 
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Anhang  C:  Höhere  Ableitungen  der  Keplerbahn 


fr  _     3([fg]  +  Tjfg]  +  21[fg]  +  35[gg])f 
dt»  ~  M[  r5 

105jg[(6[ggg  +  [fg]  +  10[gg]  +  15[fg])f 

315([fj  +  [ff])(5[fg]  +  [fg]  +  10[fg])f 

525(3[ff]  +  [fg])(4[fg]  +  [fg]  +  3[ff])f 

2205  [ff] 2  (5  [fg]  +  [rg]  +  10[fg])f     7350  [ff]  (3  [ff]  +  [fg])2f 

1 1025  [ffj(  [ff]  +  [ff])(4[fg]  +  [rg]  +  3[ff])f     11025([ff]  +  [ff])2(3[frj  +  [rg])r 

y»9  ^>9 

33075[ff]3(4[fg]  +  [rg]  +  3[rg)r     99225  [ff]  ([ff]  +  [ff])3f 
198450  [ff]  2  ([ff]  +  [ff])((3[fr]  +  [rg])r     363825  [fr]  4  (3  [fr]  +  [fg])r 

1  1  iy*  1 3 

1091475  [ff]3(([ff]  +  [ff])2)f     2837835  [ff] 5  ([ff]  +  [ff])f  2027025[ff]7f 
|  21(6[fg]  +  [rg]  +  10[gg]  +  lSggDg     630jrjK5[gg]  +  [rg]  +  lOggpg 

y5  y>7 

1050((3[ff]  +  [fg])2)f     1575([ff]  +  [ff])(4[fg]  +  [rg]  +  3[frj)f 
n025([rg  +  [fr])3)f     1 1025  [ff] 2  (4  [fg]  +  [rg]  +  3[ff])f 
44100  [r¥\([i¥\  +  [ff])(3[frj  +  [fg]f     66150[ff]3(6[ff]  +  2[fg])f 

y  9  y*  1  1 

297675  [ff] 2  ([ff]  +  [ff])2)f     1091475[ff]4([ff]  +  [ff])f  945945[ff]6f 
+  63(5[fg]  +  [rg]  +  10[fg])g     1575[r>1(4[fg]  +  [fg]  +  3[rf])g 


y5  y  7 

3150([ff]  +  [ff])(3[ff]  +  [fg])g      11025[ff]2(6[ff]  +  2[fg])g 


+ 


33075  \r'r\{\r'^  +  [ff])2g     198450  [ff]3  ([ff]  +  [ff])g  218295[ff]f 

y9  y  1 1  yl3 

|  105(4[fg]  +  [rg]  +  3[rg)g     1050[fj](6[fj  +  2[fg])g 

y  5  y  7 

1575([ff]  +  [ff])2g     22050  [ff] 2  ( [ff]  +  [ff])g  33075[ff]4g 

y7  y9  y  1  1 

105  (3  [ff]  +  [fg])g     1575[ff]([ff]  +  [ff])g  3675[ff]3g 


j   v  J   •  J  /  m      J   J  /  m  | 

y5  y7  y9 

+  63([ff]  +  [ff])g  _  315[ff]2g  +  21[ff]g  _  g 

y5  y7  y5  y3 
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d™r  _     (3(8[fg]  +  [fg]  +  35[gg)  +  56[gg]  +  28gg])r 
,  24(7[fg]  +  [fg]  +  3^[gg]  +  21[fg])f 

120[ff](7[fg]  +  [fg]  +  35[gg]  +  21[fg])f 

420([rj  +  [Fr])(6[Fg]  +  [rg]  +  10[gg]  +  15[fg])f 
,  84(6[Fg]  +  [rg]  +  10[gg]  +  15[fg])f 

840[ff](6[fg]  +  [rg]  +  10[gg]  +  15[fg])f 

2940[rr12(6[Fg]  +  [rg]  +  10[gg]  +  15[fg])f 

840(3[rg  +  [fg])(5[fg]  +  [rg]  +  10[fg])f 

2520([ff]  +  [fr])(5[fg]  +  [rg]  +  10[fg)f 

17640[fr]([ff]  +  [g)(5[fg]  +  [fg]  +  10[fg])f     168(5[fg]  +  [rg]  +  10[fg])g 


^>9  y»5 

2520[rg(5[fg]  +  [fg]  +  10gg])f  |  1 7640  [fr] 2  (5  [fg]  +  [rg]  +  10[fgDf 

iyT  y"9 

52920[rri3(5[fg]  +  [rg]  +  10[fg])f     525(4[fg]  +  [rg]  +  3[fT])2f 
4200(3^  +  [fg])(4[fg]  +  [rg]  +  3jfg)f 
29400[fj(3[rj  +  [fg])(4[fg]  +  [rg]  +  3[Ff])r 

22050([ff]  +  [ff])2(4[fg]  +  [fg]  +  3[ff])f     6300([ff]  +  [ff])(4[fg]  +  [fg]  +  3[ff])f 

y»9  y  7 

88200  [ff]  ([ff]  +  [ff])(4[fg]  +  [fg]  +  3[ff])f 

396900  [ff] 2  ([ff|  +  [ff])(4[fg]  +  [fg]  +  3[ff])f 

210(4[fg]  +  [fg]  +  3[g)g     4200[fr](4[fg]  +  [fg]  +  3[f^)g 

y5  y*7 

44100[ff]2(4[fg]  +  [fg]  +  3[ff])f     264600[ff]3(4[fg]  +  [fg]  +  3[ff])f 

^>9  y  1 1 

727650[ff]4(4[fg]  +  [fg]  +  3[ff])f     29400([ff]  +  [ff])((3[ff]  +  [fg])2)f 
~h  Tq  ~\~ 


y«13  y  9 

4200(3[rf]  +  [fg])2f     58800[ff](3  *  [rf]  +  [fg])2f     264600  [ff] 2  (3  [ff]  +  [fg])2f 

y7  y9  y  1 1 

^  88200([ff]  +  [ff])2(3[ff]  +  [fg])f     793800 [ff] ( [ff]  +  [ff])2(3[ff]  +  [fg])f 


y  9  y  1 1 
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Anhang  C:  Höhere  Ableitungen  der  Keplerbahn 


8400([ffj  +  [ff]){{3[ff])  +  [ff£])g£     1 76400  [ffj(  [ff]  +  [ffj)(3[ffj  +  [f^])f 


r^3 


1587600  [ff] 2  {[fr]  +  [ffj)(3[ffj  +  [fff])f     582 1 200  [ff] 3  {[ff]  +  [ffj)(3[ff]  +  [r§])r 


r 

168(3[ffj  +  [fg])jf     4200  [ff]  (3  [fr]  +  jggDjg     58800  [ff] 2  ( (3  [ff])  +  [fgf])gf 


11 


+ 


,13 


\zfd3f-i  \  d3f 


529200  [fr] 3  (3  [ff]  +  [fff])f     2910600[ff]4(3[ff]  +  [rf£])f     7567560  [ff] 5  (3  [ff]  +  [fff]) 


•d:ir 


?däf] 


,11 


+ 


,13 


r^i  _L  J_  y  ±<J  !y 

99225([ff]  +  [ff])4f     44100([ffj  +  [ff])3f     793800  [ff]  ([ff]  +  [ff])3f 


15 


,11 


,11 


4365900  [ff] 2  ([rg  +  [ff])3f     3150([ff]  +  [ff])2g     88200  [ff]  ([ff]  +  [fr])2|f 


1190700[ff]2([ff]  +  [ff])2f     8731800[ff]3([ff]  +  [ff])2f     28378350[ff]4([ff]  +  [ff])2f 


,ii 


+ 


iy  1  3  y  15 


84([ff]  +  [ffj)|£     2520[ff]([ff]  +  [ff])^     44100[ff]2([ff]  +  [ff]) 


y*5  y>7  ^>9 


529200  [ff] 3  ([ff1]  +  [fP])||     436j39TO[ff]4([ff]  +  [ff])f     22702680  [ff] 5  ([ff]  +  [ff])f 


,11 


,13 


,15 


56756700[ff]6([ff]  +  [ff])f     g     24  [fr]  ff     420  [ff] 2  g     5880[ff]3gg"  66150[ff]4f 


•4 


,17 


,11 


582120[ff]5g  3783780[ff]6f  16216200[ff]7f  34459425  [ff] 8^ 
+   —  +  — 


,13 


,15 


,17 


,19 


Die  folgenden  Ableitungen  werden  ausschließlich  durch  f  und  f  ausgedrückt.  Dies 
wurde  durch  Rücksubstitution  erreicht.  Diese  wird  in  Abschnitt  B  genauer  betrachtet. 
Dazu  sind  insbesondere  folgende  Ableitungen  hilfreich: 


f(t) 

df(t) 
dt 

[ff] 

2  [ff] 

[ff] 

[ff]  [ff] 

[ff] 

2  [ff] 

1 

rp 

p[fr\ 
~  rp+i 

n[ff]rn 

2n(m— 2)[rr| 

rP 

rp  —  m+l 

n[ff]rn 

nrrt[rr]m_1  [rr]  np[rr]m+1 

rP 

rP 

n[rr]m 
rP 

nra  [r  r]  m  ~ 1  [r  r]       np  [r [r m 
rP  rP+1 

C.0.2    3.Ableitung  nach  der  Zeit 
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mit 

h0  =  3[rg  =  dh\  =  dfe» 
3       r5        dt  dt 

*ä  =  -l  =  *§ 

Wobei  /ig  ein  skalarer  Faktor  von  f  und  /ig  ein  skalarer  Faktor  von  f  ist. 
Dadurch  lässt  sich      wie  folgt  schreiben: 


C.0.3    4.Ableitung  nach  der  Zeit 

d4f 

~d¥  ~  r 


d^r 

M  ((-15r[fff  -  3// [fr]  +  ^r2  +  3r3[ff])f  +  (6r3[ff])f) 


mit 


K  = 

3  [ff]  | 

[i      15[ff]2  3/x[ff] 

y6            ^*7  ^*8 

hl  = 

1  ( 6  [ff] 
2^  r5 

30[ff]2     ju[ff]  ^ 

^>7             ^8  ' 

h\  = 

1,Ä 
-( — -) 
2y  dt  ' 

h\  = 

6  [ff] 

2(3^,  =  2A» 

T,6 


Wobei     ein  skalarer  Faktor  von  f  und  h\  ein  skalarer  Faktor  von  f  ist. 


j4  -* 

Dadurch  lässt  sich  ^  wie  folgt  schreiben: 

=  fi(h°4f+hl^) 


dt4 

d^r 
dt* 


C.0.4    5.Ableitung  nach  der  Zeit 

<i5f       ,9[ff]f     45[ff][ff]f     45[ff]2f     9fj,[rr\f  ^  \ir  ^  105[ff]3f  ^  54/j[ff]  [ff]f 

^5  ^>7  y*7  ^*8  ^>6  y->9  ^-ilO 

24/i  [ff]  f 
^8  J 
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Anhang  C:  Höhere  Ableitungen  der  Keplerbahn 


Indem  ^  als  Linearkombination  aus  f  und  f  dargestellt  wird 


d5r        .,    24^[ff]     45[ff][ff]      105[ff]3     54//[ff][ff] .  _ 
9  [ff]      u  _  45  [ff] 2  _  9^[rr]  ■ 


mit 


o        24/x  [ff]     45  [ff]  [ff]      105  [ff] 3     54/x  [ff]  [ff] 

5  —  ^8  ^7  '         ^9         '  ^10 

!     9  [ff]      jU      45  [ff] 2  9/x[ff] 

5         ^5         ^6  ^7  ^8 

_     3[ff]      /x      15[ff]2     3/i[ff],  2/i 

y»5  y»6  ryT  y>8  y»6 

=  s(A8)  -  2i 

kann  ^  wie  folgt  geschrieben  werden: 

J  =  ^f+(3(^)-^)f) 

C.0.5    6.Ableitung  nach  der  Zeit 

Indem  ^  als  Linearkombination  aus  f  und  f  dargestellt  wird 

d6f_         45[ff]2     33/x[ff]     ,u2     630[ff]2[ff]     99^[ff][ff]     435/i[ff]2     33/i2[ff]  945[ff]4 

^6  ~~  ^         ^7  ^8  ^9  ^9  '  ^TÖ  '         ^TÖ         '        ^Tl  ^Ti 

SöS^fff^ff]2     54^  [ff]2 


r13 


-)f 


180[ff][ff]     66/x[ff]     420[fff  216/x[ff][ff]  v 

'            ^7                   ^8        '         ^9  '  ^10  >rl 

mit 

_  _45[ff]2  _  33/4ff]  _  /"2  +  630[ff]2[ff]  99/x[ff][ff]     435/x[ff]2     33/i2[ff]  _  945[ff]4 

^                                ry*  7                                  y«8                                                                   y>0  1 0  ya  1 0                                           1  1                                        1  1 


855 fi[fr\  [ff]2  54/i2[ff]2 


^»  12  y«13 


!_     180[ff][ff]     66^[ff]     420[ff]3  216^[ff][ff] 

6  —  ^7  ^8        '         ^9         '  ^TÖ 

kann  ^  wie  folgt  geschrieben  werden: 


C.0.6    7.Ableitung  nach  der  Zeit 

<ff  _       1575[ff][ff]2      1692//[ff] [ff]      207//2[ff]      9450[ff]3[ff]      3960// [ff]  [ff]  [ff] 
7740//[ff]3     1863//2  [ff]  [ff]      10395[ff]5     14040//  [ff]  [ff] 3     2412//2  [ff] 2  [ff] 

y  1  2  ^-»13  y»13  yl_4  yl5 

+     225[ff]2     99//[ff]     //2  +  3150[ff] 2  [ff]  +  495//  [rr]  [Ff] 

1755//[ff]2      99//2[ff]      4725[ff]4      42 75// [ff]  [ff]2      270//2[ff]2  ^ 

Indem      als  Linearkombination  aus  f  und  f  dargestellt  wird 

0  _  1575[ff][ff]2     1692 fi[ff][ff]     207//2[ff]     9450[ff]3[ff]     3960//  [rr]  [ff]  [ff] 

7740//[ff]3     1863//2  [ff]  [ff]      10395[ff]5     1 4040//  [fr]  [ff] 3     2412  fi2  [ff]2  [ff] 
!     _  225 [ff] 2  _  99// [ff]  _ //2     3150[ff]2[ff]  495//[ff][ff] 

7  ^>8  ^>9  ^>9  -^10 

1755//[ff]2     99/i2[ff]     4725[ff]4     4275//[ff]  [ff]2  270//2[ff]2 

y»l_0  y>  1  1  y  1  1  y«12  y»l_3 

kann      wie  folgt  geschrieben  werden: 


C.0.7    8.Ableitung  nach  der  Zeit 

d8f_      1575[ff]3     1917//[ff]2     306//2[ff]     42525  [ff] 2  [ff]2      //3  5535//[ff][ff]2 

575 10//  [ff] 2  [ff]     4050//2  [ff]  [ff]      11142//2[ff]2     155925[ff]4[ff]  306//3[ff] 

j^>1_2  y?13  y»13  ^13 

117990//[ff]  [ff]2  [ff]      144585//[ff]4     6372//[ff]2[ff]     69282// [ff]  [ff]2 


1/1  ~t~  1^  ~t~  K  ~t~ 


j.14  r14  r15  r15 

135135[ff]6     2133//3[ff]2     248535//[ff]  [ff]4     78300//[ff]2[ff]2     2412//3[ff]3 , 

1  ß  1  17  IQ- 


9450[ff][ff]2  7884// [ff]  [ff]  612//2  [ff]  56700  [ff] 3  [ff]  23760//[ff][ff][ff] 
_  40140//[ff]3  _  8532//2 [ff]  [ff]     62370[ff]5     84240//[ff][ff]3  14472//[ff]2[ff] 
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Indem      als  Linearkombination  aus  f  und  f  dargestellt  wird 

o  _  1575[ff]3     1917fi[ff]2     306^2[ff]     42525  [fr]  2  [rT] 2      fi3      5535/i [ff] [ffjs 


y>9  ^-«10  1 1  ^>1_1  y  1  2  ry\'2i 

57510/4ff]2[ff]     4050/x2  [ff]  [ff]      11142^2[ff]2     155925[ff]4[ff]  306//3[ff] 

y?12  ^13  ^*13  ^13 

1 1 7990^  [rr][r?] 2  [rT]      144585//[ff]4     6372//[ff] 2  [ff]     69282/x  [ff]  [ff]2 


~t~  1/1  ~t~  T/1  ~t~  K  ~t~ 


r14  r14  r15  r15 

135135[ff]6     2133/u3[ff]2     248535/x[ff]  [ff]4     78300^  [fr] 2  [ff] 2  2412^3[ff]3 


+ 


^.15  ^.16  y>16  y*17  j>18 

!  _  9450[ff][ff]2     7884^ffj[ffj     612/r2  [ff]     56700 [ff] 3 [ffj     23760//[ff] [ffj [ffj 

^  y»9  1 0  1 1  y  1 1  ty*  1 2 

40140^[frl3     8532^2  [rr\  [ffj     62370[ff]5     84240^[ff][ff]3  14472/u[ff]2[ff] 

iy\<2i  yl3  ^>13  yl4  yl5 

kann  ^  wie  folgt  geschrieben  werden: 

^  =  /i^f  +  h\?) 

C.0.8    9.Ableitung  nach  der  Zeit 

d9f_        99225  [ff]  [rT]3f     164160^^  [ff]2f     49302^2  [r^ffir 
~  ^'  ^Ti  ^12  ^13 

1091475  [ff] 3  [ff]2f     1848/r3  [ff]  f     387450/i  [rf]  [ff]  [rr]2F 

^13  ^04  '  ^14 

1731240^[ff]3  [ff]f     377622^2  [fr]  [r>][r^f     438570//2  [ff]3f 


2837835 [ff] 5  [ff]f     5 1732/i3  [ff]  [ff]  f  _  2895480^  [ff]  5f 

^15  ^16  ^16 

3269700^^  [fr]3[ff]f     488160/r2  [ff]2  [ff|[rV]f     2250990/^2  [fr]  [ff]3f 


^16  ^17 

2027025[ff]7f     214380^3  [ff]2  [ff]f     4787370/i[fr]  [ff]5f 

y»18  y»18 

2325240,u2  [ff]2  [ff]3f     200016/i3  [ff]3  [ff]f  11025[ff]3f 

^•19  ^20  y*9 

9801//[ffj2f     918/x2[ffjf     297675[ff]2[ff]2f     /i3f     38745^  [ff]  [ff] 2  f 

^-•10  1 1  ^-»11  yl2  fjv\'2i 

_  342090/4ff] 2  [ff]  f_  20466/x2 [ff]  [ffjf  _  50706//2  [ff]  2f  1091475[fr14[ff]f 

1  2  y-j]_3  y-il3  yal3 

918^3[ff]f     908145,u[ff]4f     825930^[ff]  [fr]  2  [rT]f 

^14  '  ^14  '  ^14 

44604/i2  [ff] 2  [fF]f     406026//2  [ff]  [ff]2f     945945[ff]6f     10665^  [ff] 2  f 

y»  1 5  y»15  y»15 

1739745^[ff]  [fF]4f     548100/r2  [ff]2  [ff]2f     16884//3  [ff]3f 

^16  ^17  ^08  ' 


Anhang  D 

Höhere  Ableitungen  des  Hauptproblems 


Die  Bewegungsgleichung  des  Hauptproblems  ist  wie  folgt  definiert: 


dt2 


5xz2 


Dabei  ist: 


•  die  große  Halbachse  der  Erde. 

•  ji  die  Gravitationskonstante  G  multipliziert  mit  der  Masse  der  Erde  M®. 

•  C20  der  zweite  zonale  Kugelfunktionskoeffizient  des  Gravitationspotential  der 
Erde. 

•  t  die  Zeit. 

•  a  =  |/iC2oa| 

Im  Folgenden  sind  die  höheren  Ableitungen  der  Hauptproblems  aufgeführt.  Diese 
sind  vollständig  rücksubstituiert,  d.h.  jede  der  Ableitungen  hängt  ausschließlich  vom 
Orts  -  u.  Geschwindigkeitsvektor  ab.  Folglich  sind  keine  Terme  höherer  Ableitungen 
enthalten. 


d°r 


r 


r 


d*r 
dt2 


bxz2 

5j/22 


\ 


d*r 
dt3 


r  6r[rr\ 


) 


5x  [ff]  +  I0xzz+5z2x 


+ 


35xz2  [ff]  \ 


+  Ol 
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Anhang  D:  Höhere  Ableitungen  des  Hauptproblems 


Aus  Platzgründen  wird  im  Weiteren  der  Anteil  des  Keplerproblems  zu  fxep,i  zusam- 
mengefasst.  Die  ausführliche  Darstellung  ist  in  Kapitel  C  zu  finden.  In  der  abgekürzten 
Schreibweise  steht  i  für  den  jeweiligen  Grad  der  Ableitung.  So  wird  beispielsweise  die 
1.  Ableitung  wie  folgt  bezeichnet: 


dV_  ,.  _  (±K^ 

ZKep,l, 


fKep,l  =  =  r  =  VKep,l 

V 


d4x 

^4  =  xKepA  +  a{ 

10i2  +  5[ff]     2p     35  [ff]  z2  +  35  [ff] 2  +  140  [ff]zz 

rj^T  y8  ^*9 


+ 


26/i(x2  +  y2)  -  3Afi[ff]  -  a  315[ff]V 
(50fi[ff\  +  50a)(x2  +  y2)  —  50fi[ff\2  -  55a [ff] 


4 


145az4  +  60a[ff]z2     175a  [ff]  2; 
,   20zi  +  10[ff]  70[ff]z2 

^4  =  yXep,4  +  a{ 

10i2  +  5[ff]     2p  +  35  [ff] 2 +  35  [ff]  z2  + 140  [ff]  zi 
26//(x2  +  y2)  -  34/i[ff]  -  a  315[ff]2z2 


rio  rii 
+  (50/Lt[ff]  +  50a)(x2  +  y2)  -  50/i[ff]2  -  55a[ff] 

145az4  +  60a  [ff]  z2     175a  [ff]  z4 
^04  ^06  > 

,    20zz  +  W\ff\  70[ffk2 

+y(  js^  +  ^r-} 

d4z 

^4  =  ZKeP,4  +  a{ 

15 [ff]     6/x     35[ff](x2  +  y2)  -  35  [ff]  [ff]  -  105[ff]2 

tyT  y8  ^*9 

26/i(x2  +  y2)  -  9a  -  44//[ff]     315[ff]2(x2  +  y2)  -  315[ff][ff]2 


+ 


rio  1  rii 

+  (50/x[ff]  +  90a)  (x2  +  y2)  -  50/i[ff]2  -  105a[ff] 

5a(x2  +  y2  -  [ff\)(29y2  +  29x2  -  51  [ff])  175a[ff]((x2  +  y2)  -  [ff])2, 
^  ^04  ^06  * 

.,    30([ff]  +  zi)  210[ff]z2,, 
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d5x 

■^5  =  XKep,5  +  a{ 

210[ff]i2  +  210[ff]zi  +  105[ffj[ff]      136/zzi  +  +  32ß[rr\ 

x(  I 

1890[ff]2zi  +  945[ff][ff]z2  +  315[ff]: 


rio 


240fi[fr\zz  +  150/ixxz2  +  200azi  +  15axx  +  180/z[ff][ff]  +  760//[ff]z2  +  40a[ff]  3465[ff]3z2 
^  260a  [fr]  zi  +  180axxz2  +  1200az3i  +  1380//[ff] [fr] z2  +  1520a[ff]z2  +  130a  [ff]  [ff] 


r14 


700az5i  +  1400a[ff]z3i  +  700ayyz4  +  4340a[ff]z4  +  1 820a  [ff]  [ff]  z2     5950a  [ff]  [ff]  z4N 

,06  1  ^18  > 

15[ff]+30i2     2/x     105[ff]z2  +  105[ff]2  +  420  [ff]  zi     24/i[ff|  +  58^/z2  +  32/ix2  +  a 
945[ff]2z2      (15<V  +  145az2  +  löO^z4  +  150/zyV     565az4  +  180ay2 

_  525a[ff]z4  +  700ax2z4 

ITfi  >S 


„2Z2 


d5y 

^5  =  VKep,5  +  a{ 

210[ff]z2  +  210  [ff]zz  +  105[ff][ff]      136/izz  +  32/ixx  +  32^/[ff] 
1890[ff]2zi  +  945[ff][ff]z2  +  315[ff]3 
200^z3z  +  200/xxxz2  +  240/i[ff]zi  +  180/i[ff][ff]  +  560^[ffjz2  +  220azz  +  20axx  +  20a[ff] 
3465  [ff] 3  z2 


r12 


r13 


+ 

260a[ff]zz  +  180ayyz2  +  1200az3z  +  1380/i[ffj  [ff]z2  +  1520a[ff]z2  +  130a[ff][ff] 


+ 


700az5z  +  1400a[ff]z3z  +  700axxz4  +  4340a[ff]z4  +  1 820a  [ff]  [ff]  z2     5950a  [ff]  [fr]  z4 , 

^16  '  ^18  - 

15[ff]  +  30z2     2/x     105[ff]z2  +  105[ff]2  +  420  [ff]  zi     24/i[ff]  +  58/Uz2  +  32/xy2  +  a 

9  1  ».10 

945[ff]2z2      15a[ff]  +  130az2  +  20ay2  +  150^[ff]z2  +  200/uy2z2     565az4  +  180ax 

^12  '  ^04 

525a  [ff]  z4  +  700ay  V 


,2^2 


r16  )j 
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dfi 


=  ZKep,5  +  «{ 

315  [ff]  [ff]  +  630[ff]i2  +  315[ff]zi     72/iyy  +  72fixx  +  96/t[ff] 


.10 


945[fff  +  2835[ff]2zi  +  945[ff]  [ff]z2 


,ii 


420/i[ff][ff]  +  560^[ff]z2  +  200fiz2(xx  +  yy)  +  390/xzi(x2  +  y2)  +  60a(xx  +  yy)  +  180a  [n=] 


„12 


+ 


3465  [ff]  3z2 

~L3 


1380//  [ff]  [ff]  z2  +  AAOayyz2  +  UOaxxz2  +  390a  [ff]  [ff]  +  2280a  [ff]  z2 
700axxz4  +  700ayyz4  +  4340q  [ff]  z4  +  3220a  [ff]  [ff]  z2     5950a  [ff]  [ff]  z4 

Tc  H-  To 


.     30i2  +  45[ff]     6/t     315[ff]2     9a  +  234/zz2  +  54/i[ff]     590//Z4  +  45a[ff]  +  630az2 


y»7  ^8  y9  ^-»10 


„12 


+ 


2025az4  +  690a  [ff]  z2     700az6  +  1925a  [ff]  z4 

^14  ^16  " 

D.l    Richtigkeit  der  Ergebnisse 

Im  Folgenden  werden  die  höheren  Ableitungen  auf  ihre  Genauigkeit  überprüft.  Dies 
soll  einerseits  die  Richtigkeit  der  Ableitungen  nachweisen  und  andererseits  Anwen- 
dungsfälle demonstrieren. 

D.l.l    Vergleich  der  Reihenkoeffizienten 

In  den  folgenden  Tabellen  werden  die  Potenzreihenkoeffizienten  (üQ...an)  auf  ihre  Ge- 
nauigkeit überprüft.  Die  erste  Spalte  enthält  den  Index  der  Koeffizienten.  In  der  zwei- 
ten Spalte  befindet  sich  der  berechnete  Koeffizientenwert,  gebildet  aus  den  höheren 
Ableitungen.  Als  Referenzlösung  werden  die  Koeffizienten  des  Potenzreihenintegra- 
tors verwendet.  Diese  sind  in  der  dritten  Spalte  eingetragen.  Um  die  Qualität  zu  be- 
urteilen, wurde  der  absolute  Fehler  (eafes)  in  die  vierte  Spalte  und  der  relative  Fehler 
(erei)  in  die  fünfte  Spalte  eingetragen. 


i 

a-i  berechnet 

a>i  Powserlnt 

£abs 

0 

-5020.823835619 

-5020.823835619 

0 

0 

1 

-5.150424898 

-5.150424898 

0 

0 

2 

0.32128416175413326077e-2 

0.32128416175413326077e-2 

0.50e-50 

0.17e-47 

3 

0. 1 1054906 1 8349545987 le-5 

0. 1 1054906 1 8349545987 le-5 

0.26e-53 

0.24e-47 

4 

-0.33936694289394860835e-9 

-0.33936694289394860835e-9 

0.32e-57 

0.94e-48 

5 

0.73999074230564 1 1 6092e- 1 3 

-0.73999074230564 1 1 6092e- 1 3 

0.93e-60 

0.13e-46 

Tabelle  D.  1 :  Vergleich  der  Reihenterme  (X-Komponente) 
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i 

dj  berechnet 

üi  Powserlnt 

£abs 

0 

62.177071042 

62.177071042 

0 

0 

1 

-0.25747324e-l 

-0.25747324e-l 

0 

0 

2 

-0.397873 1 14 1 3592603205e-4 

-0.3978731 1413592603205e-4 

0.42e-52 

0.11e-47 

3 

0.540649 1706 1 8 1 33224 1 le-8 

0.540649 1706 1 8 1 33224 1 le-8 

0.26e-55 

0.47e-47 

4 

0.4264 1787555594467289e- 1 1 

0.4264 1787555594467289e- 1 1 

0.99e-59 

0.23e-47 

5 

-0.30833344955564757635e-15 

-0.30833344955564757635e-15 

0.30e-62 

0.99e-47 

Tabelle  D.2:  Vergleich  der  Reihenterme  (Y-Komponente) 


i 

a-i  berechnet 

a,i  Powserlnt 

£abs 

0 

4547.497626756 

4547.497626756 

0 

0 

1 

-5.680500488 

-5.680500488 

0 

0 

2 

-0.29 1 835 1 65  896 1 3 1 89055e-2 

-0.29183516589613189055e-2 

0.53e-50 

0.18e-47 

3 

0. 12089105654256080856e-5 

0. 12089105654256080856e-5 

0.40e-53 

0.32e-47 

4 

0.31626884457524858571e-9 

0.31626884457524858571e-9 

0.96e-57 

0.30e-47 

5 

-0.74944 1 74955735097  825e- 1 3 

-0.74944 174955735097825e- 13 

0.86e-60 

0.11e-46 

Tabelle  D.3:  Vergleich  der  Reihenterme  (Z-Komponente) 


Der  Vergleich  der  Reihenterme  zeigt,  dass  diese  im  Rahmen  der  hier  verwende- 
ten numerischen  Genauigkeit  übereinstimmen  (siehe  eabs)-  Die  Zunahme  des  relati- 
ven Fehlers  (ere/)  in  den  höheren  Reihentermen  resultiert  aus  der  erhöhten  Anzahl  an 
Rechenoperationen.  Diese  verursachen  einen  Zuwachs  des  Rundungsfehlers,  welcher 
nicht  vermieden  werden  kann. 


D.1.2    Vergleich  der  Ortskoordinaten 

Durch  Einsetzen  der  höheren  Ableitungen  in  eine  Taylorreihe  und  deren  Auswertung 
zu  einem  bestimmten  Zeitpunkt  erhält  man  eine  weitere  Möglichkeit,  die  Qualität  der 
Ergebnisse  zu  beurteilen.  Die  berechneten  Ortskoordinaten  aus  der  Taylorreihe  kön- 
nen anschließend  mit  einer  Referenzlösung  verglichen  werden  (eabs)-  In  Abbildung 
D.l  wurde  eine  Bahn  mit  Hilfe  der  LiDIA-Bibliothek  und  dem  Potenzreihenintegra- 
tor berechnet  und  mit  der  Taylorreihenlösung  verglichen.  Dabei  zeigt  sich,  dass  der 
absolute  Fehler  nach  60  Sekunden  für  die  X  und  Z-Komponente  im  fim  und  für  die 
Y- Komponente  im  10  nm-Bereich  liegt.  Eine  sukzessive  Auswertung  mit  Hilfe  der 
Taylorreihenlösung  ist  daher  nur  in  sehr  kurzen  Schritten  möglich.  Da  die  Taylorreihe 
des  Hauptproblems  sehr  langsam  konvergiert,  werden  viele  Reihenterme  benötigt,  um 
einen  größeren  Zeitraum  in  einem  Schritt  auszuwerten.  Erschwerend  kommt  hinzu, 
dass  die  Kompliziertheit  der  analytischen  Darstellung  mit  steigendem  Grad  der  Ablei- 
tung zunimmt.  Dies  macht  die  Ausarbeitung  weiterer  Terme  und  deren  anschließende 
Rücksubstitution  zu  einer  nahezu  unlösbaren  Aufgabe,  die  lediglich  durch  Computer 

Algebra  Systeme  bewältigt  werden  kann.  Vielversprechende  Softwarepakete  dazu  sind  cas  Computer  Alge- 
bra Systeme 
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MATHEMATICA1,  MAXIMA2  und  SymbolicC++3. 

0.0001 
le-06 
le-OS 
le-10 
le-12 
le-14 
le-16 
le-18 
le-20 

0  20  40  50  SO  100 

tW 

Abbildung  D.l:  Absoluter  Fehler  in  Meter  [m] 


D.1.3    Vergleich  der  Rechenzeit 

Beim  Rechenzeitvergleich  (auf  Testplattform  1,  siehe  Abschnitt  A.l)  zeigen  sich  die 
Stärken  der  analytischen  Lösung  gegenüber  dem  Potenzeihenintegrator.  Bei  der  Be- 
rechnung einer  Potenzreihe  mit  Hilfe  des  Potenzreihenintegrators  fallen  eine  ganze 
Reihe  von  Funktionsaufrufen  an,  die  Rechenzeit  benötigen.  Außerdem  sind  die  Re- 
chenoperationen zur  Verknüpfung  von  Potenzreihen  rekursiv  definiert4,  was  eine  Par- 
allelisierung  durch  den  Compiler  auf  Assemblerebene  nahezu  unmöglich  macht.  Die 
Berechnung  der  analytisch  erarbeiteten  Lösung  erfolgt  deutlich  schneller  als  die  des 
Potenzreihenintegrators  (siehe  dazu  D.2).  Außerdem  kann  ein  bestimmter  Reihenterm 
ohne  vorheriges  Berechnen  der  vorangegangenen  Ableitungen  ermittelt  werden.  Dies 
ist  der  Rücksubstitution  zu  verdanken,  da  diese  Lösung  ausschließlich  von  Ort  -  und 
Geschwindigkeitsvektor  abhängt. 


'http://www.wolfram.com/ 

2  http :  //maxima.  sourceforge.net/ 

3http://issc.uj.ac.za/symbolic/symbolic.html 

4  siehe  dazu  auch  [Wanner68]  und  [Schneider92] 
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Abbildung  D.2:  Vergleich  der  Rechenzeit  zur  Lösung  des  Hauptproblems  mit  verschie- 
denen Datentypen.  Der  Xdouble-Datentyp  berücksichtigt  64  signifikante  Nachkomma- 
stellen; der  LiDIA-Datentyp  wurde  auf  32  signifikante  Nachkommastellen  eingestellt 
und  der  long  double  -  Datentyp  verwendet  definitionsgemäß  16  signifikante  Nachkom- 
mastellen 
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Anhang  E 


Formeln  zur  numerischen  Berechnung  von 
höheren  Ableitungen 


Es  wurden  die  folgenden  Funktionswerte  verwendet:  Zur  Bestimmung  der 

Lösungsformeln  wur- 

f(-9h  +  X0),f(-8h  +  X0),f(-7h  +  Xo),f(-6h  +  X0)  de   das  Computeral- 

f(-5h  +  xo),  f{-4h  +  *„),  f(Sh  +  x0),  f(-2h  +  x0) 
f(h  +  x0),f(+x0),  f(h  -  x0) 
f(2h  +  x0),  f(Sh  +  x0),  f(4h  +  x0),  f(5h  +  x0) 
f(6h  +  x0),  /(7/i  +  x0),  f(8h  +  x0),  /(9/i  +  x0) 

Durch  Auflösung  des  Gleichungssystems  nach  den  jeweiligen  Unbekannten  /',...,  /^18^ 
ergeben  sich  folgende  Lösungsformeln: 

f'{Xo)  =  12252240/1  (~28/(~9fe  +  Xo)  +  567^~8h  +  x°)  "  5508/("7/l  +  *o) 
+  34272/(-6/i  +  x0)  -  154224/(-5/i  +  x0)  +  539784/(-4/i  +  x0) 

-  1559376/(-3/i  +  x0)  +  4009824/(-2/i  +  x0)  -  11027016/(-/i  +  x0) 
+  11027016/(/i  +  x0)  -  4009824/(2/i  +  x0)  +  1559376/(3/1  +  x0) 

-  539784/(4/i  +  x0)  +  154224/(5/i  +  x0)  -  34272/(6/i  +  x0) 
+  5508/(7/i  +  x0)  -  567/(8/i  +  x0)  +  28/(9/i  +  x0)) 

_  fe18/(19)(c) 
923780 

r(*0)  =  15437822400^  (-47541321542/(^)  +  +  *o) 

-  178605/(-8/i  +  x0)  +  1982880/(-7/i  +  x0)  -  14394240/(-6/i  +  x0) 

+  77728896/ (-5/i  +  x0)  -  340063920/(-4/i  +  x0)  +  1309875840/(-3/i  +  x0) 

-  5052378240/(-2/i  +  x0)  +  27788080320/(-/i  +  x0)  +  27788080320/ (h  +  x0) 

-  5052378240/(2/1  +  x0)  +  1309875840/(3/i  +  x0)  -  340063920/ {Ah  +  x0) 
+  77728896/(5/i  +  x0)  -  14394240/(6/i  +  x0)  +  1982880/(7/i  +  x0) 

-  178605/(8/i  +  x0)  +  7840/(9/i  +  x0)) 

/i18/(2°)(c) 
9237800 
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/(3)(Xo)  =  3027024000^  (63397/(~9/l  +  Xo)  "  1281033/("8/j  +  *o) 

+  12405267/(-7/i  +  x0)  -  76813928/(-6/i  +  x0)  +  342868500/(-5/i  +  x0) 

-  1182036366/(-4/i  +  x0)  +  3302404924/(-3/i  +  x0)  -  7666346376/(-2/i  +  x0) 
+  8823005334/(-/i  +  x0)  -  8823005334/(/i  +  x0)  +  7666346376/(2/i  +  x0) 

-  3302404924/(3/1  +  x0)  +  1 182036366/(4/1  +  x0)  -  342868500/(5/*  +  x0) 
+  76813928/(6/i  +  x0)  -  12405267/(7/i  +  x0)  +  1281033/(8/i  +  x0) 

514639/i16/(19)(c) 


-  63397/(9/i  +  x0))  + 


51459408000 


/(4)(Xo)  =  54486432000^ (842762184550/(X0)  "  507176/("9/i  +  *o) 

+  11529297/(-8/i  +  x0)  -  127597032/(-7/i  +  x0)  +  921767136/(-6/i  +  x0) 

-  4937306400/(-5/i  +  x0)  +  21276654588/(-4/i  +  x0)  -  79257718176/(-3/i  +  x0) 
+  275988469536/(-2/i  +  x0)  -  635256384048/(-/i  +  x0)  -  635256384048/(/i  +  x0) 
+  275988469536/(2/1  +  x0)  -  79257718176/(3/i  +  x0)  +  21276654588/(4/i  +  x0) 

-  4937306400/(5/1  +  x0)  +  921767136/(6/i  +  x0)  -  127597032/(7/i  +  x0) 
+  11529297/(8/1  +  x0)  -  507176/(9/i  +  x0)) 

514639/i16/(20)(c) 


+ 


257297040000 


/(5)(Xo)  =  21794572800/15  (~3739217/(~9/l  +  Xo)  +  75119112/("8/i  +  *o) 

-  721271943/(-7/i  +  x0)  +  4407497768/ {-6h  +  x0)  -  19241468100/(-5/i  +  x0) 

+  63619040016/(-4/i  +  x0)  -  161682804556/(-3/i  +  x0)  +  275637687624/(-2/i  +  x0) 

-  246459164094/(-/i  +  x0)  +  246459164094/(/i  +  x0)  -  275637687624/(2/i  +  x0) 
+  161682804556/(3/1  +  x0)  -  63619040016/(4/i  +  x0)  +  19241468100/(5/i  +  x0) 

-  4407497768/(6/1  +  x0)  +  721271943/(7/i  +  x0)  -  75119112/(8/i  +  x0) 

364919/i14/(19)(c) 


+  3739217/(9/1  +  x0))  - 


4358914560 


/(6)(X0)  =  32691859200^  (~2697076863910/(X0)  +  3739217/("9/l  +  x^ 

-  84509001/(-8/i  +  x0)  +  927349641/(-7/i  +  x0)  -  6611246652/(-6/i  +  x0) 

+  34634642580/ (-5h  +  x0)  -  143142840036/(-4/i  +  x0)  +  485048413668/(-3/i  +  x0) 

-  1240369594308/(-2/i  +  x0)  +  2218132476846/(-/i  +  x0)  +  2218132476846/(/i  +  x0) 

-  1240369594308/(2/1  +  x0)  +  485048413668/(3/i  +  x0)  -  143142840036/(4/i  +  x0) 
+  34634642580/(5/*  +  x0)  -  6611246652/(6/i  +  x0)  +  927349641/(7/i  +  x0) 

364919/i14  f^tc) 

-  84509001/(8/*  +  x0)  +  3739217/(9/*  +  x0))  -  ^4529715200 
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/(7)(Xo)  =  11404800^  (14037/(~9/l  +  Xo)  ~  278998/("8/j  +  *o) 

+  2637347/(-7/i  +  x0)  -  15732348/(-6/i  +  x0)  +  65988500/(-5/i  +  x0) 

-  202775476/(-4/i  +  x0)  +  443422524/(-3/i  +  x0)  -  641013196/(-2/i  +  x0) 
+  510956534/(-/i  +  x0)  -  510956534/(/i  +  x0)  +  641013196/(2/i  +  x0) 

-  443422524/(3/1  +  x0)  +  202775476/(4/i  +  x0)  -  65988500/(5/1  +  x0) 
+  15732348/(6/1  +  x0)  -  2637347/(7/i  +  x0)  +  278998/(8/i  +  x0) 

5839219/i12/(19)(c) 


-  14037/(9/i  +  x0))  + 


9340531200 


/(8)(Xo)  =  119750400^  (5014508785°/(:ro)  "  131012/(-9/*  +  *o) 

+  2929479/(-8/i  +  x0)  -  31648164/(-7/i  +  x0)  +  220252872/(-6/i  +  x0) 

-  1108606800/(-5/i  +  x0)  +  4258284996/(-4/i  +  x0)  -  12415830672/(-3/i  +  x0) 
+  26922554232/(-2/i  +  x0)  -  42920348856/(-/i  +  x0)  -  42920348856/(/i  +  x0) 
+  26922554232/(2/1  +  x0)  -  12415830672/(3/i  +  x0)  +  4258284996/(4/i  +  x0) 

-  1108606800/(5/1  +  x0)  +  220252872/(6/i  +  x0)  -  31648164/(7/i  +  x0) 

5839219ft,12/(20)(c) 


+  2929479/(8/1  +  x0)  -  131012/(9/i  +  x0))  + 


23351328000 


f(9)(x0)  =  80641Q0/i9(-6063/(-9/i  +  x0)  +  118448/(-8/i  +  x0)  -  1092217/(-7/i  +  x0) 

+  6276192/(-6/i  +  x0)  -  24816700/(-5/i  +  x0)  +  69370784/(-4/i  +  x0) 

-  135969204/(-3/i  +  x0)  +  178778336/(-2/i  +  x0)  -  133953346/(-/i  +  x0) 
+  133953346/(/i  +  x0)  -  178778336/(2/i  +  x0)  +  135969204/(3/i  +  x0) 

-  69370784/(4/1  +  x0)  +  24816700/(5/i  +  x0)  -  6276192/(6/i  +  x0) 
+  1092217/(7/i  +  x0)  -  118448/(8/i  +  x0)  +  6063/(9/i  +  x0)) 

_  21713/i10/(19)(c) 
5322240 

/(1°)(Xo)  =  24192Wö("459622540/(xo)  +  2021f(-9h  +  xo) 

-  44418/(-8/i  +  x0)  +  468093/(-7/i  +  x0)  -  3138096/(-6/i  +  x0) 

+  14890020/(-5/i  +  x0)  -  52028088/(-4/i  +  x0)  +  135969204/(-3/i  +  x0) 

-  268167504/(-2/i  +  x0)  +  401860038/(-/i  +  x0)  +  401860038/(/i  +  x0) 

-  268167504/(2/1  +  x0)  +  135969204/(3/i  +  x0)  -  52028088/(4^  +  x0) 
+  14890020/(5/i  +  x0)  -  3138096/(6/i  +  x0)  +  468093/(7/i  +  x0) 

_  44418/(8/i  +  x0)  +  2021/(9/i  +  x0)) 

_  21713/i10/(2°)(c) 
10644480 
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/(11)(xo)  =  20160fr11  (757/(~9/l  +  x^  ~  14408/("8/l  +  xo) 

+  128107/(-7/i  +  x0)  -  699088/(-6/i  +  x0)  +  2573500/(-5/i  +  x0) 

-  6638576/(-4/i  +  x0)  +  12076484/(-3/i  +  x0)  -  14976656/(-2/i  +  x0) 
+  10816894/(-/i  +  x0)  -  10816894/(/i  +  x0)  +  14976656/(2/i  +  x0) 

-  12076484/(3/i  +  x0)  +  6638576/(4/i  +  x0)  -  2573500/(5/i  +  x0) 
+  699088/(6/i  +  x0)  -  128107/(7/i  +  x0)  +  14408/(8/i  +  x0) 

/(12)(x0)  =  15121Q/tl2(109965350/(x0)  -  757/(-9/i  +  x0) 

+  16209/(-8/i  +  x0)  -  164709/(-7/i  +  x0)  +  1048632/(-6/i  +  x0) 

-  4632300/(-5/i  +  x0)  +  14936796/(-4/i  +  x0)  -  36229452/(-3/i  +  x0) 
+  67394952/(-2/i  +  x0)  -  97352046/(-/i  +  x0)  -  97352046/(/i  +  x0) 

+  67394952/(2/1  +  x0)  -  36229452/(3/i  +  x0)  +  14936796/(4/i  +  x0) 

-  4632300/(5/i  +  x0)  +  1048632/(6/i  +  x0)  -  164709/(7/i  +  x0) 

5473/i8/(20)(c) 


+  16209/(8/i  +  x0)  -  757/(9/i  +  x0))  + 


403200 


/(13)(x0)  =  (-69/(-9/i  +  x0)  +  1264/(-8/l  +  x0) 

-  10691/(-7/i  +  x0)  +  54816/(-6/i  +  x0)  -  188900/(-5/i  +  x0) 
+  458272/(-4/i  +  x0)  -  792012/(-3/i  +  x0)  +  945568/(-2/i  +  x0) 

-  667238/(-/i  +  x0)  +  667238/(/i  +  x0)  -  945568/(2/i  +  x0) 
+  792012/(3/1  +  x0)  -  458272/(4/i  +  x0)  +  188900/(5/i  +  x0) 

-  54816/(6/i  +  x0)  +  10691/(7/i  +  x0)  -  1264/(8/i  +  x0) 

619/i6/(19)(c) 


+  69/(9/i  +  x0))  - 


6048 


/(14)(Xo)  =  72W4  (-1570426°/(^o)  +  161/(-9/i  +  x0) 

-  3318/(-8/i  +  x0)  +  32073/(-7/i  +  x0)  -  191856/(-6/i  +  x0) 

+  793380/(-5/i  +  x0)  -  2405928/(-4/i  +  x0)  +  5544084/(-3/i  +  x0) 

-  9928464/(-2/i  +  x0)  +  14011998/(-/t  +  x0)  +  14011998/(/i  +  x0) 

-  9928464/(2/i  +  x0)  +  5544084/(3/i  +  x0)  -  2405928/(4/i  +  x0) 
+  793380/(5/i  +  x0)  -  191856/(6/i  +  x0)  +  32073/(7/i  +  x0) 

-  3318/(8/i  +  x0)  +  161/(9/i  +  x0)) 

619fr6/(2°)(c) 
8640 
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f(15)(xo)  =        (3/(-9/i  +  x0)  -  52/(-8/i  +  x0) 

+  413/(-7/i  +  x0)  -  1992/(-6/i  +  x0)  +  6500/(-5/t  +  x0) 

-  15064/(-4/i  +  so)  +  25116/(-3/i  +  x0)  -  29224/(-2/i  +  x0) 
+  20306/ (-/i  +  x0)  -  20306/(/i  +  x0)  +  29224/(2/i  +  x0) 

-  25116/(3/i  +  x0)  +  15064/(4/i  +  x0)  -  6500/(5/i  +  x0) 
+  1992/(6/i  +  x0)  -  413/(7/i  +  x0)  +  52/(8/i  +  x0) 

-3/(9/l  +  x0))  +  ^/l4/(19)(c) 

/(16)(^o)  =        (135850/(x0)  -  2f(-9h  +  x0)  +  39/(-8/i  +  x0) 

-  354/(-7/i  +  x0)  +  1992/(-6/i  +  x0)  -  7800/(-5/i  +  x0) 

+  22596/(-4/i  +  x0)  -  50232/(-3/i  +  x0)  +  87672/(-2/i  +  x0) 

-  121836/(-/i  +  x0)  -  121836/(/i  +  x0)  +  87672/(2/i  +  x0) 

-  50232/(3/i  +  x0)  +  22596/(4/i  +  x0)  -  7800/(5/i  +  x0) 
+  1992/(6/1  +  x0)  -  354/(7/i  +  x0)  +  39/(8/i  +  x0) 

-2/(9/l  +  x0))  +  ^/l4/(20)(c) 


/(17)(^o)  =  ^iy(-/(-9/j  +  *o)  +  16/(-8/i  +  x0) 

-  119/(-7/i  +  x0)  +  544/(-6/i  +  x0)  -  1700/(-5/i  +  x0) 
+  3808/(-4/t  +  x0)  -  6188/(-3/i  +  x0)  +  7072/(-2/i  +  x0) 

-  4862/(-/i  +  x0)  +  4862/(/i  +  x0)  -  7072/(2/i  +  x0) 
+  6188/(3/i  +  x0)  -  3808/(4/i  +  x0)  +  1700/(5/i  +  x0) 

-  544/(6/i  +  x0)  +  119/(7/i  +  x0)  -  16/(8/i  +  x0) 

+  /(9^  +  Xo))_^2/(19)(c) 

/(18)(*o)  =  ^  (-48620/(x0)  +  f(-9h  +  x0) 

-  18/(-8/i  +  x0)  +  153/(-7/i  +  x0)  -  816/(-6/i  +  x0) 

+  3060/(-5/i  +  x0)  -  8568/(-4/i  +  x0)  +  18564/(-3/i  +  x0) 

-  31824/(-2/i  +  x0)  +  43758/(-/i  +  x0)  +  43758/(/i  +  x0) 

-  31824/(2/i  +  x0)  +  18564/(3/i  +  x0)  -  8568/(4/i  +  x0) 
+  3060/(5/i  +  x0)  -  816/(6/i  +  x0)  +  153/(7/t  +  x0) 

-  18/(8/1  +  x0)  +  /(9/i  +  so))  "  7^2/(20)(c) 
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Anhang  F 


Auswertungsprotokolle,  Statistiken  und 
zusätzliche  Ergebnisse 


El    Auswertung  des  ACOVEA  Testlaufs 

Im  Folgenden  ist  das  ACOVEA  Protokoll  der  Simulation  Abschnitt  5.4.2  auf  Seite  127 
abgedruckt. 

Äcovea   5.1.1    (cornpiled  Jul   24   2010  14:48:24) 
Evolving  Better  Software 


Invented  by  Scott  Robert  Ladd 

Coyote  Gulch  Productions 


( scott . ladd@coyotegulch . com) 
(http : / /www . coyotegulch . com) 


test  applicat ion 
test  System 
conf ig  de script ion 
test  conf iguration 
acovea  version 
evocosm  version 
applicat ion  version 


TestDecimal . cpp 
mart in 

g++     Pentium     (version  1.0.0) 
. . / conf ig/g++4 . 3_pentium . acovea 
5.1.1 
3.1.0 

g++-4 .3  4.6.0 


#  of  populations: 
Population  size: 
survival  rate : 
migration  rate : 
mutation  rate: 
crossover  rate: 
fitness  scaling: 
generations  to  run : 
random  number  seed : 
testing  mode : 


16 

10%  (2) 
5%  (1) 
1% 

100% 
sigma 

2 

3384417609 
speed 


test  Start  time:   2011  Jun  23  13:07:00 


generat ion  1  begins 


Population  1 

Population  2 

Population  3 

Population  4 


generation  1  complete,   average  fitness :   0 . 003646 


generat ion  2  begins 


Population  1 

population  2 

Population  3 

population  4 


generation  2  complete,   average  fitness :   0 . 00226784 

Äcovea  completed  its  analysis  at  2011  Jun  23  13:12:48 
Optimistic  options : 

-f no-cprop-registers  (1.522) 

-f no-tree-dse  (1 .  522 ) 

-f no-tree-ter  (1 . 522 ) 

-f schedule-insns2  (2.158) 
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-falign-labels  (2.158) 

-ftree-vectorize  (1.522) 

-falign-loops  (1 .  522) 

-ffloat-store  (2.793) 

-fpeel-loops  (1 . 522) 

-f no-f unction-cse  (1.522) 

-ftree-loop-linear  (2.158) 

Pessimistic  options : 


leaf-f rame-pointer 

(-2 

29) 

branch-probability 

(  - 

655) 

-f no-if-conversion 

(-1 

655) 

-f strict-aliasing 

(  - 

655) 

-mf pmath=3  87 

(  - 

655) 

-mfpmath=sse,  387 

(-2 

29) 

-msse4 . 1 

(-2 

29) 

-msse4 . 2 

(-2 

29) 

D  NO_MATH_INLINES 

(  - 

655) 

Acovea' s  Best-of-the-Best : 

g++-4 . 3  -lrt  -Im  -Ol  -march=nocona  -f no-merge-const ant s  -f no-thread- jumps  -f no-delayed-branch  -f no-tree-dse 

-f no-t ree-ter  -f no-t ree-lrs  -f opt imize-sibling-calls  -f rerun-loop-opt  -fpeephole2  -f schedule-insns 

-f schedule-insns2  -f sched-spec  -f delete-null-pointer-checks  -f reorder-blocks  -f unit-at-a-time  -falign- jumps 

-falign-loops  -falign-labels  -ftree-pre  -f st rict-over f low  -f inline-f unctions  -f unswitch-loops  -f gcse-af ter-reload 

-f predi et ive- common ing  -falign- f unctions  -falign- jumps  -falign-labels  -f pref etch-loop-arrays 

-ftree-vect-loop- version  -ffloat-store  -f pref etch-loop-arrays  -f unswitch-loops  -f unroll-loops 

-fbranch-target-load-optimize  -f no-f unction-cse  -fgese-sm  -f reschedule-modulo-scheduled-loops  -ftree-loop-linear 
-f t ree-loop-im  -f t ree-loop-ivcanon  -ftree-vectorize  -mieee-fp  -mno-push-args  -maccumulate-outgoing-args 
-mno-align-stringops  -f inline-limit=800  -o  /tmp/ACOVEA7D244FF9  TestDecimal . epp 

Acovea' s  Common  Options : 

g++-4 . 3  -lrt  -Im  -Ol  -march=nocona  -f opt imize-sibling-calls  -f schedule-insns2  -falign-labels  -f st rict-overf low 
-f unswitch-loops  -ffloat-store  -f pref et ch-loop-arrays  -f no-f unction-cse  -f gese-sm  -ftree-loop-linear  -mieee-fp 
-maccumulate-outgoing-args  -o  / tmp/ACOVEA25E3B7F3  TestDecimal . epp 


-Ol: 

g++-4.3  -lrt  -Im  -Ol  -march=nocona  -o  /tmp/ACOVEA4C799B19  TestDecimal . epp 
-02: 

g++-4.3  -lrt  -Im  -02  -march=nocona  -o  /tmp/ACOVEAB02ElC7D  TestDecimal . epp 
-03: 

g++-4.3   -lrt   -Im  -03   -march=nocona   -o   /tmp/ACOVEA3A091C62   TestDecimal . epp 

-Os: 

g++-4.3   -lrt   -Im  -Os   -march=nocona   -o   /tmp/ACOVEACFD776F7   TestDecimal . epp 


A  relative  graph  of  f itnesses : 


Acovea' s  Best-of-the-Best 
Acovea' s  Common  Options 
-Ol 
-02 
-03 
-Os 


(0 

001716) 

(0 

001955) 

(0 

003309) 

(0 

002548) 

(0 

003172) 

(0 

002714) 

Acovea  is  done. 


F.3  Konfigurationsdateien 
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F.2    Anzahl  der  aktiven  GCC  Optimierungsoptionen  bei  be- 
stimmten Optimierungsstufen 


Version 

00 

Ol 

02 

03 

Os 

Gesamt 

gcc-3.3 

12 

11 

37 

39 

43 

74 

gcc-3.4 

10 

9 

39 

43 

45 

87 

gcc-4.0 

17 

18 

46 

49 

53 

116 

gcc-4.1 

19 

19 

46 

49 

54 

126 

gcc-4.2 

19 

19 

46 

49 

54 

126 

gcc-4.3 

56 

56 

77 

82 

74 

136 

gcc-4.4 

55 

55 

80 

87 

80 

155 

gcc-4.5 

68 

68 

92 

98 

93 

166 

gcc-4.6 

30 

30 

62 

68 

70 

192 

gcc-4.7 

30 

30 

63 

69 

71 

193 

Tabelle  F.  1 :  Übersicht  zur  Anzahl  der  aktivierten  GCC  Optimierungsoptionen 


F.3  Konfigurationsdateien 


F.3.1  Lorenz.conf 


1 

<ODE> 

2 

<InitialValues> 

3 

Name  =  Experimentl 

4 

x  =10 

5 

y  =20 

6 

z  =30 

7 

</  InitialValues> 

8 

<Parameter> 

9 

a     =  10 

10 

b     =  28 

11 

c    =  2.6666666666666666666666 

12 

</  Parameter> 

13 

</ODE> 

Listing  F.l:  Die  Konfigurationsdatei:  Lorenz.conf 
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F.4    Ergebnisse  der  Keplerbahnsimulation 

Hier  werden  noch  weitere  Ergebnisse  zu  den  Experimenten  auf  Seite  54  angegeben.  In 
den  Abbildungen  El,  E2  und  E3  ist  der  absolute  Fehler  für  die  jeweiligen  Simulati- 
onszeiträume aufgetragen. 

0.01     r  1  1  1  1  1  n 


le-10    "  1  1  1  1  1  1 

0  1000  2000  3000  4000  5000  6000 

Zeit  [s] 

Abbildung  Fl:  Absoluter  Fehler  über  den  Simulationszeitraum  eines  Umlaufs  für  den 
double  und  long  double  Datentyp 
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0  10000  20000  30000  40000  50000  60000  70000  BOOO0  90000 

Zeit  [s] 

Abbildung  F.2:  Absoluter  Fehler  über  den  Simulationszeitraum  eines  Tages  für  den 
double  und  long  double  Datentyp 


BS,  double 
BS,  long  double 
SG,  double 
SG,  long  double 
DOP,  double 
DOP,  long  double 


0  100000  200000  300000  400000  500000  600000  70000C 

Zeit  [s] 

Abbildung  F.3:  Absoluter  Fehler  über  den  Simulationszeitraum  von  sieben  Tagen  für 
den  double  und  long  double  Datentyp 
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F.5  Ergebnisse  der  Leistungsmessungen 
F.5.1  Basisfunktionen 


Increment 


1000 


E  100 


10 


60  80  100  120 

signifikante  Nachkommastellen 


Li  DIA 


MAPM 


NTL 


CLN 


GMP 


Decrement 
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Abbildung  F.4:  Leistungsmessung  zu  Inkrement  und  Dekrement  Operationen  auf  Test- 
plattform 1 


F.5.2  Exponentialfunktion 
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Abbildung  F.5:  Messergebnisse  zur  Exponentialfunktion  (Testplattform  1) 


F.5.3  Quadratwurzel 
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Abbildung  F.6:  Messergebnisse  zur  Quadratwurzel  (Testplattform  1) 


F.5.4    Sinus  Hyperbolicus 
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Sinus  Hyperbolicus 
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Abbildung  F.7:  Messergebnisse  der  sinh -Funktion  (Testplattform  1) 


E5.5    Kosinus  Hyperbolicus 
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Abbildung  F.  8:  Messergebnisse  der  cosh  -Funktion  (Testplattform  1) 


E5.6    Tangens  Hyperbolicus 
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Tangens  Hyperbolicus 
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Abbildung  F.9:  Messergebnisse  der  tan-Funktion  (Testplattform  1) 


F.5.7    Arcus  Sinus 
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Abbildung  F.  10:  Messergebnisse  der  asin-Funktion  (Testplattform  1) 


F.5.8    Arcus  Kosinus 
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Abbildung  RH:  Messergebnisse  der  acos-Funktion  (Testplattform  1) 


F.5.9    Arcus  Tangens 
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Abbildung  R12:  Messergebnisse  der  atan -Funktion  (Testplattform  1) 


F.6    Vergleich  zweier  Lösungen  des  Erde-Mond  Abstands 
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Abbildung  F.  13:  Vergleich  zweier  Lösungen  des  Erde -Mond  Abstands  (Teilausschnitt) 
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Anhang  G 


Programme 


G.l    TMP  Vorlagen 

G.l.l    Eine  einfache  TMP-for-Schleife  als  Klassentemplate 


1  template<  int   ilndex  >  class  For 

2  { 

3  public  : 

4  static   inline   void  LoopQ 

5  { 

6  For<  ilndex— 1  >::Loop(); 

7  } 

8  }; 

9  template  <>  class  For<  0  > 

10  { 

11  public  : 

12  static   inline   void  LoopQ 

13  {} 

14  }; 


Listing  G.l:  TMP-for-Schleife 


G.1.2    Eine  zweifach  geschachtelte  TMP-for-Schleife  als  Klassentempla- 
te 


1  template<  int   i  >  class  InnerFor 

2  ! 

3  public  : 

4  static   inline   void  LoopQ 

5  ! 

6  InnerFor<  i— 1  >::Loop(); 

7  } 

8  }; 

9  template  <>  class   InnerFor<  0  > 

10  { 

11  public  : 

12  static   inline   void  LoopQ 

13  {} 

14  }; 
15 
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16  template<  int   i  >  class  For 

17  { 

18  public: 

19  static   inline   void  Loop() 

20  { 

21  For<  i-l    >::Loop()  ; 

22  InnerFor  <  i  >::Loop(); 

23  1 

24  }; 

25  template  <>  class  For<  0  > 

26  { 

27  public  : 

28  static   inline   void  Loop() 

29  {} 

30  ); 


Listing  G.2:  TMP-for-Schleife 


G.1.3    Verschiedene  TMP-wMe-Schleifen 


In  diesem  Abschnitt  werden  zwei  verschiedene  Methoden  zur  Umsetzung  einer  TMP- 
while -Schleife  angegeben,  wobei  die  Methode  in  Listing  G.3  als  Klassentemplate  und 
die  Methode  in  Listing  G.4  als  Funktionstemplate  realisiert  sind. 


1 

template<int  I>  class  While 

2 

{ 

3 

public  : 

4 

static   inline   void  Run() 

5 

{ 

6 

While<  (   (I-l)   !=  0  )   ?  (I-l) 

0>::Run()  ; 

7 
8 

) 

); 

9 

template  <>  class  While<0> 

10 

{ 

11 

public  : 

12 

static   inline   void  Run(){} 

13 

}; 

Listing  G3:  TMP-wM/e-Schleife  realisiert  als  Klassentemplate 


1 

template  <int  I>  inline 

void  While  () 

2 

{ 

3 

While<  (    (I-l)   !=  0 

)   ?   (I-l)   :   0  >(); 

4 

} 

5 

template  <>  inline  void 

While  <0>(){} 

Listing  G4:  TMP-  while -Schleife  realisiert  als  Funktionstemplate 


G.1.4  TMP-if-eise-Struktur 


1  template<  bool  Condition  >  class  If 

2  ! 

3  public  : 

4  static   inline   void  Run() 
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5  ! 

6  //  true 

7  } 

8  }; 

9  template  <>  class   If<  false  > 

10  { 

11  public  : 

12  static   inline   void  Run() 

13  { 

14  //  false 

15  j 

16  }; 


Listing  G.5:  TMP-if-eise -Struktur  realisiert  als  Klassentemplate 


1  template  <bool   Condidition>  inline   void   If  () 

2  1 

3  //  true 

4  } 

5  template  <>  void  If<false>() 

6  1 

7  //false 

8  } 


Listing  G.6:  TMP-if-eise -Struktur  realisiert  als  Funktionstemplate 


G.1.5    TMP-switch-case  Kontrollstruktur 


1  enum  CaseType 

2  1 

3  CASE1.CASE2 

4  }; 

5 

6  template<  CaseType  >  class  Switch 

7  1 


8  public  : 

9  static    inline   void  EvalQ 

10  { 

11  //   d  efa  u  1 1 

12  j 


13  }; 

14  template  <>  class   Switch<  CASE1  > 

15  { 

16  public  : 

17  static    inline   void  EvalQ 

18  { 

19  //  Fall  1 

20  j 

21  }; 

22  template  <>  class   Switch  <  CASE2  > 

23  { 


24  public  : 

25  static    inline   void  EvalQ 

26  { 

27  //  Fall  2 
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28  } 

29  }; 


Listing  G.7:  TMP- switch-case -Struktur  realisiert  als  Klassentemplate 


1 

enum  CaseType 

2 

{ 

3 

CASE1,CASE2 

4 

I; 

5 

6 

template  <CaseType>  inli 

ne    void   Switch  () 

7 

{ 

8 

//  d  efa  u  1 1 

9 

} 

10 

template  <>  inline  void 

Switch  <CASE1>() 

11 

{ 

12 

//   Fall  1 

13 

} 

14 

template  <>  inline  void 

Switch  <CASE2>() 

15 

{ 

16 

//   Fall  2 

17 

} 

Listing  G.8:  TMP-switcfi-case-Struktur  realisiert  als  Funktionstemplate 


G.1.6    TMP-Funktion  zur  Berechnung  der  Fakultät 


Im  Folgenden  ist  ein  Programm  zur  Berechnung  der  Fakultät  angegeben.  Hierbei  wird 
die  Berechnung  der  Fakultät  vollständig  während  der  Übersetzungsphase  durchge- 
führt. 


1 

2 

template  <unsigned 

long  N,  typename  T> 

inline  T 

Fact ( void ) 

3 

{ 

return  (N==0)  ? 

1    :  N*  Fact  <(N  >  0  ? 

N-l   :  0) 

,T>()  ; 

4 

} 

Listing  G.9:  C++-TMP-Funktion  zur  Berechnung  der  Fakultät 


G.1.7    TMP-Funktion  zur  Potenzberechnung 

Im  Folgenden  ist  das  Programm  zu  Potenzberechnung  dargestellt.  Hierfür  wird  eine 
weitere  Hilfsfunktion  Sqr  benötigt.  Diese  berechnet  das  Quadrat  aus  einer  gegebenen 
Gleitkommazahl. 


1 

2  template  <typename  T>  static    inline  T  Sqr(const  T  &x) 

3  1 

4  return  x*x; 

5  } 
6 

7  template  <int  P,  typename  T>  inline  T  Pow(const  T  &x) 

8  1 

9  return  (P  ==  0)  ?  1 

10  :    ((P<0)   ?    l/Pow<(P<0)?-P:0 ,T>(x) 

11  :    ((P%2)  ?  x*Sqr(Pow<(P%2) 
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12  ?   (P-l)/2    :  0,T>(x)) 

13  :    Sqr(Pow<(P%2)  ?  0   :  P/2,T>(x))) 

14  ); 

15  } 


Listing  G.10:  C++-TMP-Funktion  zur  Potenzberechnung 


G.2    Automatisches  Differenzieren 


G.3    Resultat  aus  Berechnung  des  Rückwärtsmodus 


1  void   dKepler ( double  *x,    double  *xb ,    double  *y ,    double   *yb ,    double   *z , 


double 

2  *zb,    double  *vx ,    double  *vxb ,    double  *vy ,    double  *vyb ,  double 

*vz  , 

3  double  *vzb)  { 

4  double  r ,  _x ,   _y ,   _z ; 

5  double  rb  ,   _xb ,   _yb ,   _zb ; 

6  double   tempb2  ; 

7  double   tempbl  ; 

8  double   tempbO  ; 

9  double  tempb  ; 

10  _x  =  *x; 

11  _y  =  *y; 

12  _z  =  *z  ; 

13  r  =   sqrt(_x*_x  +  _y*_y  +  _z*_z); 

14  pushreal8 ( r ) ; 

15  r=r*(r*r); 

16  tempb2  =  -  (0.39860044 1 5000000E+6*(* vxb )/ r ) ; 

17  tempbl  =   -  (0.39860044 1 5000000E+6*(* vyb )/ r ) ; 

18  tempb  =   -(0.39860044 1 5000000E+6*(*  vzb  )/ r  )  ; 

19  rb  =  — (_y*tempbl  /  r  )  —  _x*tempb2/r  —  _z*tempb/r; 

20  *vzb  =  *zb  ; 

21  * vyb  =  *yb  ; 

22  *vxb  =  *xb  ; 

23  popreal8(&r) ; 

24  rb  =  3*(r*r)*rb  ; 

25  if  (_x*_x  +  _y*_y  +  _z*_z  ==  0.0) 

26  tempbO  =  0.0; 

27  eise 

28  tempbO  =  rb /( 2 . 0 *  s qr t ( _x*_x+_y *_y+_z *_z ) )  ; 

29  _zb  =  2*_z*tempb0  +  tempb; 

30  _yb  =  2*_y*tempb0  +  tempbl  ; 

31  _xb  =  2*_x*tempb0  +  tempb2  ; 

32  *zb  =  _zb  ; 

33  *yb  =  _yb ; 

34  *xb  =  _xb ; 


35  } 


Listing  G.ll:  Resultat  aus  Berechnung  des  Rückwärtsmodus 
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